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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Jul-87 16:03:37 EDT
From:      CRB@NIHCUDEC.BITNET ("C. BACON")
To:        comp.protocols.tcp-ip
Subject:   DECnet-TCP/IP gateway?

Looking for gateway software, preferably layered atop Wollongong,
for a MicroVax.  In and out via shared DEQNA.
Mail is the biggest need.  FTP strongly desired.  Telnet desired,
but let's be realistic.

        Charles Bacon, CRB@NIHCUDEC (bitnet)
(OK to send braces $ and caret X now)

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Jul-87 16:03:37 EDT
From:      CRB@NIHCUDEC.BITNET ("C. BACON")
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for PC/IX?

PC/IP has opened up the DOS side of my aging XT marvelously.
But PC/IX languishes for the moment.
Does anyone know of a port of PC/IP or other TCP/IP for PC/IX?
Free preferred, of course.

[Usual disclaimer: I am a satisfied customer of free software, etc.]

        Chuck Bacon, CRB@NIHCUDEC (bitnet)

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Wed, 01 Jul 87  16:03:37  EDT
From:      "C. BACON" <CRB%NIHCUDEC.BITNET@wiscvm.wisc.edu>
To:        <tcp-ip@sri-nic.arpa>
Cc:        <CRB@NIHCUDEC>
Subject:   DECnet-TCP/IP gateway?
Looking for gateway software, preferably layered atop Wollongong,
for a MicroVax.  In and out via shared DEQNA.
Mail is the biggest need.  FTP strongly desired.  Telnet desired,
but let's be realistic.

        Charles Bacon, CRB@NIHCUDEC (bitnet)
(OK to send braces $ and caret X now)
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Wed, 01 Jul 87  16:03:37  EDT
From:      "C. BACON" <CRB%NIHCUDEC.BITNET@wiscvm.wisc.edu>
To:        <tcp-ip@sri-nic.arpa>
Cc:        <CRB@NIHCUDEC>
Subject:   TCP/IP for PC/IX?
PC/IP has opened up the DOS side of my aging XT marvelously.
But PC/IX languishes for the moment.
Does anyone know of a port of PC/IP or other TCP/IP for PC/IX?
Free preferred, of course.

[Usual disclaimer: I am a satisfied customer of free software, etc.]

        Chuck Bacon, CRB@NIHCUDEC (bitnet)
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 01 Jul 87 17:33:19 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Asyncio on Sockets
I know this is a Unix question and not really appropriate here,
but Berkeley and Sun people seem to read this list a lot.

Has anyone found problems setting async io on a RAW IP socket?
Under 3.2 on a Sun, it just doesn't seem to work; at least I
never get a SIGIO even when I see packets (using a net wathcer)
arriving at the machine. The manual pages and tutorials are somewhat
thin in this area.

Also, when using asyncio on a UDP socket, the process doesn't
get a SIGIO unless it has had another signal first.

Jon
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Jul 87 11:53:33 -0400
From:      Mike Brescia <brescia%ccv.bbn.com@CCV.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        kirschen%multimax.arpa@CCV.BBN.COM
Subject:   connection establish timeout query

I would interpret this question as "What should the open timeout be for
telnet, ftp, and mail user and server programs?" What sort of numbers are used
in the software?

    mike

---- forwarded message ----

Received:  by multimax.ARPA (4.12/25-eef)
	id AA02553; Wed, 1 Jul 87 09:02:23 edt
Date: Wed, 1 Jul 87 09:02:23 edt
From: David Kirschen <kirschen@multimax.ARPA>
Message-Id: <8707011302.AA02553@multimax.ARPA>
Subject: Arpanet Timeouts

Hi - Could you tell me if there is a way to determine if we are
seeing a reasonable number of connection timeouts over the Arpanet?
We get lots of connections failing, for various applications (mail, ftp,
telnet).  We'd like to know what the commonly used  timeout constant
is (i.e., how long should it take when establishing a connection before
the initiator just gives up?).  Thanks !!
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Jul-87 17:45:23 EDT
From:      mo@SEISMO.CSS.GOV (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for SCO Xenix 2.2 on AT's and 386's


We have seen the Micom product.  Anybody have any
comments about it, and has anybody seen anything
else which would work in this setting.
	-Mike

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Jul-87 21:40:45 EDT
From:      lekash@ORVILLE.ARPA (John Lekashman)
To:        comp.protocols.tcp-ip
Subject:   Re: NSC HyperchannelB - Ethernet TCP/IP gateway

hi.
There are things that will move IP packets between hyperchannels
and other networks.

vaxes running bsd.
suns.

Various vendors have mentioned the idea of building it into
their gatways.

Most that I have seen operate on hyperchannel A, the 50 mbit
version.  Porting to hyperchannel B should not be that
hard.  We just don't have any, because ethernets are so
much cheaper.

There is a spec from NSC on how to encapsulate IP over
hyperchannel.  It will likely occur as an RFC one day soon.

The distribution hyperchannel driver on a BSD tape is broken,
and doesn't follow this spec besides.

I have drivers for:
vaxes running 4.3 BSD.  (4.2 is trivial from that)
silicon graphics Irises, running 3.5 (or it may be 3.6 by now)

you can have these for free.  Wollongong has installed this driver
on a VMS vax for us, you can probably give them some amount
of money for it, but they shouldn't charge you much, because 
I gave it to them.

Availability: public ftp from orville.arpa.  I don't guarantee it is
as up to date as whatever I last built.  I'll probably copy
the current version over next week.  Upgrades include things
to deal with special NSC hardware, so its no great need.

					john

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Jul-87 05:58:03 EDT
From:      hedrick@topaz.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   revised TCP/IP document, part I of II


The following is a revised (and I hope final) version of the TCP/IP
introduction I posted a week ago.  It takes into account comments that
I got from a number of helpful people, and adds a good deal of extra
material.  Originally, I intended it to give my own staff enough
background to read the RFC's.  It appears that there was a need for a
bit more general introduction.  I have tried to do that, to the extent
that I could.

Various people asked for permission to distribute it to their staff
(or even customers).  I have added a copyright that tries to make it
clear that this is OK.

If you don't have TCP/IP, and this convinces you that you should get
it, the NIC (whose address is given in the last section) has a list of
implementations.  However these days, most equipment vendors can
supply TCP/IP, or point you to a 3rd party who can.

This posting is in two parts, because inews claimed that postings over
64K bytes were a bad idea.

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












                             Introduction
                                  to
                        the Internet Protocols





                      C                       R

                              C       S
                  Computer Science Facilities Group
                              C       I

                      L                       S


                               RUTGERS
                  The State University of New Jersey




                             3 July 1987

This is an introduction to the Internet networking protocols (TCP/IP).
It  includes  a  summary  of  the  facilities  available   and   brief
descriptions of the major protocols in the family.

Copyright  (C)  1987,  Charles  L. Hedrick.  Anyone may reproduce this
document, in whole or in  part,  provided  that:    (1)  any  copy  or
republication  of  the entire document must show Rutgers University as
the source, and must include this notice; and (2)  any  other  use  of
this  material  must reference this manual and Rutgers University, and
the fact that the material is copyright by Charles Hedrick and is used
by permission.



Unix is a trademark of AT&T Technologies, Inc.
 


                          Table of Contents


   1. What is TCP/IP?                                                1
   2. General description of the TCP/IP protocols                    5
       2.1 The TCP level                                             7
       2.2 The IP level                                             10
       2.3 The Ethernet level                                       11
   3. Well-known sockets and the applications layer                 12
       3.1 An example application: SMTP                             15
   4. Protocols other than TCP: UDP and ICMP                        17
   5. Keeping track of names and information: the domain system     18
   6. Routing                                                       20
   7. Details about Internet addresses: subnets and broadcasting    21
   8. Datagram fragmentation and reassembly                         23
   9. Ethernet encapsulation: ARP                                   24
   10. Getting more information                                     25






































                                  i
 


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.    It  can  give  you  a reasonable idea of the
capabilities of the protocols.  But if you need to know any details of
the  technology,  you  will  want  to  read  the  standards  yourself.
Throughout the text, you will find references to the standards, in the
form of "RFC" or "IEN" numbers.  These are document numbers. The final
section of this  document  tells  you  how  to  get  copies  of  those
standards.



1. What is TCP/IP?


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.  The most accurate name for the  set  of
protocols we are describing is the "Internet protocol suite".  TCP and
IP are two of the protocols in this suite.  (They  will  be  described
below.)    Because  TCP and IP are the best known of the protocols, it
has become common to use the term TCP/IP or IP/TCP  to  refer  to  the
whole  family.  It is probably not worth fighting this habit.  However
this can lead to some oddities.  For example, I  find  myself  talking
about  NFS as being based on TCP/IP, even though it doesn't use TCP at
all.  (It does use IP.  But it  uses  an  alternative  protocol,  UDP,
instead  of TCP.  All of this alphabet soup will be unscrambled in the
following pages.)

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 that 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.  Users can  send  messages  from
any  of  them  to  any other, except where there are security or other
policy restrictions on 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 provide
                                  1
 


"low-level" functions needed for many applications.  These include IP,
TCP, and UDP.  (These will be described in a bit more  detail  later.)
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.      Initially  TCP/IP  was  used  mostly  between
minicomputers or mainframes.  These machines had their own disks,  and
generally  were self-contained.  Thus the most important "traditional"
TCP/IP services are:

   - file transfer.  The file transfer protocol (FTP) allows a user on
     any computer to get files from another computer, or to send files
     to another computer.  Security is handled by requiring  the  user
     to  specify  a  user  name  and  password for the other computer.
     Provisions are made for handling file transfer  between  machines
     with different character set, end of line conventions, etc.  This
     is not quite the same thing as more recent "network file  system"
     or  "netbios"  protocols, which will be described below.  Rather,
     FTP is a utility that you run any time you want to access a  file
     on  another  system.    You  use  it to copy the file to your own
     system.  You then work with the local copy.   (See  RFC  959  for
     specifications for FTP.)

   - remote  login.    The network terminal protocol (TELNET) allows a
     user to log in on any other computer on the network.  You start a
     remote session by specifying a computer to connect to.  From that
     time until you finish the session, anything you type is  sent  to
     the  other  computer.   Note that you are really still talking to
     your own computer.  But the telnet program effectively makes your
     computer invisible while it is running.  Every character you type
     is sent directly to the other system.  Generally, the  connection
     to  the  remote  computer  behaves much like a dialup connection.
     That is, the remote system will ask you to  log  in  and  give  a
     password, in whatever manner it would normally ask a user who had
     just dialed it up.  When you log off of the other  computer,  the
     telnet  program exits, and you will find yourself talking to your
     own computer.  Microcomputer implementations of telnet  generally
     include  a  terminal  emulator  for some common type of terminal.
     (See RFC's 854 and 855 for specifications for  telnet.    By  the
     way,  the  telnet protocol should not be confused with Telenet, a
     vendor of commercial network services.)

   - computer mail.  This allows you to  send  messages  to  users  on
     other  computers.    Originally, people tended to use only one or
     two specific computers.  They  would  maintain  "mail  files"  on
     those machines.  The computer mail system is simply a way for you
     to add a message to another user's mail file.    There  are  some
     problems  with  this  in  an environment where microcomputers are
     used.  The most serious is that a micro is  not  well  suited  to
     receive  computer  mail.    When you send mail, the mail software
     expects to be able  to  open  a  connection  to  the  addressee's
     computer, in order to send the mail.  If this is a microcomputer,
     it may be turned off, or it may be running an  application  other
     than  the mail system.  For this reason, mail is normally handled
     by a larger system, where it is practical to have a  mail  server
     running all the time.  Microcomputer mail software then becomes a
                                  2
 


     user interface that retrieves mail from the mail  server.    (See
     RFC  821  and  822 for specifications for computer mail.  See RFC
     937 for a protocol designed for microcomputers to use in  reading
     mail from a mail server.)  

These  services  should  be  present  in any implementation of TCP/IP,
except that micro-oriented implementations may  not  support  computer
mail.  These traditional applications still play a very important role
in TCP/IP-based networks.  However more recently,  the  way  in  which
networks  are  used has been changing.  The older model of a number of
large, self-sufficient computers is beginning to  change.    Now  many
installations    have    several   kinds   of   computers,   including
microcomputers, workstations, minicomputers, and  mainframes.    These
computers  are  likely  to be configured to perform specialized tasks.
Although people are still likely to work with one  specific  computer,
that  computer  will  call on other systems on the net for specialized
services.  This has  led  to  the  "server/client"  model  of  network
services.    A server is a system that provides a specific service for
the rest of the network.  A client is another system  that  uses  that
service.    (Note  that the server and client need not be on different
computers.  They could be  different  programs  running  on  the  same
computer.)    Here  are  the  kinds  of servers typically present in a
modern computer setup.  Note that these computer services can  all  be
provided within the framework of TCP/IP.

   - network  file  systems.   This allows a system to access files on
     another computer in a somewhat more  closely  integrated  fashion
     than FTP.  A network file system provides the illusion that disks
     or other devices from one system are directly connected to  other
     systems.    There  is no need to use a special network utility to
     access a file on another system.  Your computer simply thinks  it
     has  some  extra disk drives.  These extra "virtual" drives refer
     to the other system's disks.    This  capability  is  useful  for
     several different purposes.  It lets you put large disks on a few
     computers, but still give others access to the disk space.  Aside
     from the obvious economic benefits, this allows people working on
     several computers  to  share  common  files.    It  makes  system
     maintenance  and  backup  easier, because you don't have to worry
     about updating  and  backing  up  copies  on  lots  of  different
     machines.    A  number  of  vendors  now  offer  high-performance
     diskless computers.  These computers have no disk drives at  all.
     They  are  entirely dependent upon disks attached to common "file
     servers".   (See  RFC's  1001  and  1002  for  a  description  of
     PC-oriented   NetBIOS   over   TCP.     In  the  workstation  and
     minicomputer area, Sun's Network File System is more likely to be
     used.    Protocol  specifications  for  it are available from Sun
     Microsystems.)

   - remote printing.  This allows you to  access  printers  on  other
     computers  as if they were directly attached to yours.  (The most
     commonly used protocol is the remote  lineprinter  protocol  from
     Berkeley  Unix.  Unfortunately, there is no protocol document for
     this.  However the C code is easily obtained  from  Berkeley,  so
     implementations are common.)

                                  3
 


   - remote  execution.   This allows you to request that a particular
     program be run on a different computer.  This is useful when  you
     can  do  most  of  your work on a small computer, but a few tasks
     require the resources of a larger system.  There are a number  of
     different  kinds  of remote execution.  Some operate on a command
     by command basis.  That is, you request that a  specific  command
     or  set  of commands should run on some specific computer.  (More
     sophisticated versions will choose a system that  happens  to  be
     free.)    However  there are also "remote procedure call" systems
     that allow a program to  call  a  subroutine  that  will  run  on
     another  computer.    (There  are  many  protocols  of this sort.
     Berkeley Unix contains two servers to execute commands  remotely:
     rsh  and  rexec.   The man pages describe the protocols that they
     use.  The user-contributed software with Berkeley 4.3 contains  a
     "distributed  shell"  that  will  distribute tasks among a set of
     systems, depending upon load.  Remote procedure  call  mechanisms
     have  been  a  topic  for research for a number of years, so many
     organizations have implementations of such facilities.  The  most
     widespread commercially-supported remote procedure call protocols
     seem to be Xerox's Courier and Sun's RPC.  Protocol documents are
     available  from  Xerox and Sun.  There is a public implementation
     of Courier over TCP as part of the user-contributed software with
     Berkeley  4.3.   An implementation of RPC was posted to Usenet by
     Sun, and also appears as part of  the  user-contributed  software
     with Berkeley 4.3.)

   - name  servers.    In  large  installations, there are a number of
     different collections of names that have to  be  managed.    This
     includes  users  and their passwords, names and network addresses
     for computers, and accounts.  It becomes  very  tedious  to  keep
     this data up to date on all of the computers.  Thus the databases
     are kept on a small number of systems.  Other systems access  the
     data over the network.  (RFC 822 and 823 describe the name server
     protocol used to keep track of host names and Internet  addresses
     on  the  Internet.    This  is  now a required part of any TCP/IP
     implementation.  IEN 116 describes an older name server  protocol
     that is used by a few terminal servers and other products to look
     up host names.  Sun's  Yellow  Pages  system  is  designed  as  a
     general  mechanism to handle user names, file sharing groups, and
     other databases commonly used by Unix  systems.    It  is  widely
     available  commercially.    Its  protocol definition is available
     from Sun.)

   - terminal servers.  Many installations no longer connect terminals
     directly  to  computers.    Instead they connect them to terminal
     servers.  A terminal server is simply a small computer that  only
     knows  how  to  run  telnet  (or some other protocol to do remote
     login).  If your terminal is  connected  to  one  of  these,  you
     simply  type the name of a computer, and you are connected to it.
     Generally it is possible to have active connections to more  than
     one  computer  at  the  same time.  The terminal server will have
     provisions to switch between connections rapidly, and  to  notify
     you  when  output  is  waiting for another connection.  (Terminal
     servers use the telnet protocol, already mentioned.  However  any
     real terminal server will also have to support name service and a
                                  4
 


     number of other protocols.)

   - network-oriented  window  systems.      Until   recently,   high-
     performance  graphics  programs had to execute on a computer that
     had  a  bit-mapped  graphics  screen  directly  attached  to  it.
     Network  window  systems  allow  a  program to use a display on a
     different computer.  Full-scale network window systems provide an
     interface  that  lets you distribute jobs to the systems that are
     best  suited  to  handle  them,  but  still  give  you  a  single
     graphically-based  user  interface.  (The most widely-implemented
     window system is X. A  protocol  description  is  available  from
     MIT's  Project  Athena.  A reference implementation is publically
     available from MIT.  A number  of  vendors  are  also  supporting
     NeWS,  a window system defined by Sun.  Both of these systems are
     designed to use TCP/IP.)  

Note that some of the  protocols  described  above  were  designed  by
Berkeley,  Sun,  or other organizations.  Thus they are not officially
part of the Internet protocol suite.   However  they  are  implemented
using  TCP/IP, just as normal TCP/IP application protocols are.  Since
the protocol definitions are not  considered  proprietary,  and  since
commercially-support  implementations  are  widely  available,  it  is
reasonable to think of these protocols as being  effectively  part  of
the  Internet  suite.   Note that the list above is simply a sample of
the sort of services  available  through  TCP/IP.    However  it  does
contain   the  majority  of  the  "major"  applications.    The  other
commonly-used protocols tend to be specialized facilities for  getting
information  of  various  kinds, such as who is logged in, the time of
day, etc.  However if you need a facility that is not listed here,  we
encourage  you  to  look  through  the  current  edition  of  Internet
Protocols (currently RFC 1011),  which  lists  all  of  the  available
protocols,   and   also   to   look   at  some  of  the  major  TCP/IP
implementations to see what various vendors have added.



2. General description of the TCP/IP protocols


TCP/IP is a layered set of protocols.  In  order  to  understand  what
this  means,  it is useful to look at an example.  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 datagram, e.g. the text of the mail, TCP will  split  it
up  into  several  datagrams,  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
                                  5
 


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  datagrams  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.)  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.   Datagrams  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.  (It is 254 because 0 and  255  are  not  allowed,  for
reasons  that  will  be  discussed  later.)  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
                                  6
 


address.  (RFC 882 describes the name server technology used to handle
this lookup.)

TCP/IP is  built  on  "connectionless"  technology.    Information  is
transfered  as  a sequence of "datagrams".  A datagram is a collection
of data that is sent as a single message.  Each of these datagrams  is
sent  through  the network individually.  There are provisions to open
connections (i.e.  to start a conversation that will continue for some
time).    However at some level, information from those connections is
broken up into datagrams, and  those  datagrams  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
datagram.   So the protocols will break this up into something like 30
500-octet datagrams.  Each of these datagrams  will  be  sent  to  the
other  end.    At  that point, they will be put back together into the
15000-octet file.  However while those datagrams are in  transit,  the
network doesn't know that there is any connection between them.  It is
perfectly possible  that  datagram  14  will  actually  arrive  before
datagram  13.    It is also possible that somewhere in the network, an
error will occur, and some datagram won't get through at all.  In that
case, that datagram has to be sent again.

Note  by  the way that the terms "datagram" and "packet" often seem to
be nearly interchangable.  Technically, datagram is the right word  to
use  when  describing  TCP/IP.  A datagram is a unit of data, which is
what the protocols deal with.  A packet is a physical thing, appearing
on an Ethernet or some wire.  In most cases a packet simply contains a
datagram, so there is  very  little  difference.    However  they  can
differ.  When TCP/IP is used on top of X.25, the X.25 interface breaks
the datagrams up into 128-byte packets.   This  is  invisible  to  IP,
because  the  packets  are put back together into a single datagram at
the other end before being processed by TCP/IP.  So in this case,  one
IP  datagram  would  be carried by several packets.  However with most
media, there are efficiency advantages to  sending  one  datagram  per
packet, and so the distinction tends to vanish.



2.1 The TCP level


Two separate protocols are involved in handling TCP/IP datagrams.  TCP
(the "transmission control protocol") is responsible for  breaking  up
the  message  into  datagrams,  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 datagrams.  It may seem like TCP is  doing  all  the  work.
And  in  small networks that is true.  However in the Internet, simply
getting a datagram to its  destination  can  be  a  complex  job.    A
connection  may require the datagram 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
                                  7
 


that  the  interface  between TCP and IP is fairly simple.  TCP simply
hands IP a datagram with a destination.   IP  doesn't  know  how  this
datagram relates to any datagram before it or after it.

It  may  have occurred 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 datagram to the right  destination.    TCP  has  to  know  which
connection  this  datagram  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 datagram 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 manageable chunks.  (In order to do this, TCP
has to know how large a datagram your network can handle.    Actually,
the TCP's at each end say how big a datagram they can handle, and then
they pick the smallest size.)  

   ....   ....   ....   ....   ....   ....   ....   ....

TCP puts a header at the front of each datagram.  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 datagram, this becomes the "source" port number, since you  are  the
source  of  the  datagram.    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
datagram 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 datagram has a sequence number.  This  is  used  so
that  the  other  end  can make sure that it gets the datagrams in the
right  order,  and  that  it  hasn't  missed  any.    (See   the   TCP
specification for details.)  TCP doesn't number the datagrams, but the
octets.  So if there are 500 octets of  data  in  each  datagram,  the
first datagram 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 datagram
                                  8
 


(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 datagram in transmission, and it is
thrown away.  So here's what the datagram looks like now.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Source Port          |       Destination Port        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Acknowledgment Number                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Data |           |U|A|P|R|S|F|                               |
    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
    |       |           |G|K|H|T|N|N|                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |         Urgent Pointer        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   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....

You will note that there are items in  the  header  that  I  have  not
described  above.    They  are  generally  involved  with managing the
connection.  In order to make sure the datagram  has  arrived  at  its
destination,  the  recipient  has  to  send back an "acknowledgement".
This is a datagram whose "Acknowledgement number" field is filled  in.
For  example,  sending  a  packet  with  an  acknowledgement  of  1500
indicates that you have received all the data up to octet number 1500.
If  the  sender  doesn't  get  an  acknowledgement within a reasonable
amount of time, it sends the data  again.    The  window  is  used  to
control  how  much  data can be in transit at any one time.  It is not
practical to wait for each datagram to be acknowledged before  sending
the  next  one.    That would slow things down too much.  On the other
hand, you can't just keep sending, or a fast  computer  might  overrun
the  capacity  of  a slow one to absorb data.  Thus each end indicates
how much new data it is currently prepared to absorb  by  putting  the
number  of  octets  in  its  "Window" field.  As the computer receives
data, the amount of space left in its window decreases.  When it  goes
to  zero, the sender has to stop.  As the receiver processes the data,
it increases its window, indicating that it is ready  to  accept  more
data.  Often the same datagram can be used to acknowledge receipt of a
set of data and to give permission for  additional  new  data  (by  an
updated  window).  The "Urgent" field allows one end to tell the other
to skip ahead in its processing to a particular octet.  This is  often
useful  for  handling asynchronous events, for example when you type a
control character or other command that interrupts output.  The  other
fields are beyond the scope of this document.



                                  9
 


2.2 The IP level


TCP  sends each of these datagrams 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
datagram, or even in the TCP header.  IP's job is  simply  to  find  a
route for the datagram and get it to the other end.  In order to allow
gateways or other intermediate systems to  forward  the  datagram,  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 datagram 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
datagram to go.)  The protocol number tells IP at  the  other  end  to
send  the  datagram  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 datagram to.  Finally, the checksum allows IP at
the other end to verify that the header  wasn't  damaged  in  transit.
Note  that TCP and IP have separate checksums.  IP needs to be able to
verify that the header didn't get damaged in transit, or it could send
a  message to the wrong place.  For reasons not worth discussing here,
it is both more efficient and safer to have  TCP  compute  a  separate
checksum  for  the  TCP  header  and  data.  Once IP has tacked on its
header, here's what the message looks like:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |Type of Service|          Total Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live |    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....

Again,  the  header contains some additional fields that have not been
discussed.  Most of them are beyond the scope of this document.    The
flags  and fragment offset are used to keep track of the pieces when a
datagram has to be split up.   This  can  happen  when  datagrams  are
forwarded through a network for which they are too big.  (This will be
discussed a bit more below.)  The time to live is  a  number  that  is
decremented  whenever  the  datagram passes through a system.  When it
goes to zero, the datagram is discarded.  This is done in case a  loop
                                  10
 


develops  in the system somehow.  Of course this should be impossible,
but  well-designed  networks  are  built  to  cope  with  "impossible"
conditions.

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
datagrams 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).



2.3 The Ethernet level


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:





                                  11
 


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       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

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
datagram up to IP.  IP removes the IP header.   It  looks  at  the  IP
protocol  field.    Since  the  protocol  type  is  TCP, it passes the
datagram up to TCP.  TCP now looks at the sequence number.    It  uses
the  sequence  numbers  and  other  information  to  combine  all  the
datagrams 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,  RFC  793  for  TCP,  RFC  791  for IP, and RFC's 894 and 826 for
sending IP over Ethernet.)



3. Well-known sockets and the applications layer


So far, we have described how a stream  of  data  is  broken  up  into
datagrams,  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
                                  12
 


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 FTP 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 FTP server.    This  is  done  by  having
"well-known  sockets"  for  each  server.    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  datagram  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  FTP.    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.
                                  13

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Jul-87 05:59:22 EDT
From:      hedrick@topaz.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP intro, part II of II


 


Now  that  we  know  how  to  open  connections, let's get back to the
applications programs.  As mentioned earlier, 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
                                  14
 


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.



3.1 An example application: SMTP


In order to give a bit better idea what is involved in the application
protocols,  I'm  going  to  show an example of SMTP, which is the mail
protocol.  (SMTP is "simple mail transfer protocol.)  We assume that a
computer called TOPAZ.RUTGERS.EDU wants to send the following message.

  Date: Sat, 27 Jun 87 13:26:31 EDT
  From: hedrick@topaz.rutgers.edu
  To: levy@red.rutgers.edu
  Subject: meeting

  Let's get together Monday at 1pm.

First,  note  that the format of the message itself is described by an
Internet standard (RFC 822).  The standard specifies the fact that the
message  must be transmitted as net ASCII (i.e. it must be ASCII, with
carriage return/linefeed to delimit lines).   It  also  describes  the
general  structure, as a group of header lines, then a blank line, and
then the body of the message.  Finally, it describes the syntax of the
header  lines in detail.  Generally they consist of a keyword and then
a value.

Note  that  the  addressee  is  indicated   as   LEVY@RED.RUTGERS.EDU.
Initially,  addresses were simply "person at machine".  However recent
standards have made things more flexible.  There  are  now  provisions
for  systems  to handle other systems' mail.  This can allow automatic
forwarding on behalf of computers not connected to the Internet.    It
can be used to direct mail for a number of systems to one central mail
server.  Indeed there is no requirement that an actual computer by the
name  of RED.RUTGERS.EDU even exist.  The name servers could be set up
so that you mail to department names, and each  department's  mail  is
routed  automatically to an appropriate computer.  It is also possible
that the part before the @ is something other than a user name.  It is
possible  for  programs  to be set up to process mail.  There are also
provisions  to  handle  mailing  lists,  and  generic  names  such  as
                                  15
 


"postmaster" or "operator".

The  way  the  message is to be sent to another system is described by
RFC's 821 and 974.  The program that is going to be doing the  sending
asks  the  name server several queries to determine where to route the
message.  The first query is to find out which  machines  handle  mail
for  the  name RED.RUTGERS.EDU.  In this case, the server replies that
RED.RUTGERS.EDU handles its own mail.  The program then asks  for  the
address of RED.RUTGERS.EDU, which is 128.6.4.2.  Then the mail program
opens a TCP connection to port 25  on  128.6.4.2.    Port  25  is  the
well-known  socket  used  for receiving mail.  Once this connection is
established, the mail program starts sending  commands.    Here  is  a
typical  conversation.  Each line is labelled as to whether it is from
TOPAZ or RED.  Note that TOPAZ initiated the connection:

    RED    220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT
    TOPAZ  HELO topaz.rutgers.edu
    RED    250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU
    TOPAZ  MAIL From:<hedrick@topaz.rutgers.edu>
    RED    250 MAIL accepted
    TOPAZ  RCPT To:<levy@red.rutgers.edu>
    RED    250 Recipient accepted
    TOPAZ  DATA
    RED    354 Start mail input; end with <CRLF>.<CRLF>
    TOPAZ  Date: Sat, 27 Jun 87 13:26:31 EDT
    TOPAZ  From: hedrick@topaz.rutgers.edu
    TOPAZ  To: levy@red.rutgers.edu
    TOPAZ  Subject: meeting
    TOPAZ
    TOPAZ  Let's get together Monday at 1pm.
    TOPAZ  .
    RED    250 OK
    TOPAZ  QUIT
    RED    221 RED.RUTGERS.EDU Service closing transmission channel

First, note that commands all use normal text.  This is typical of the
Internet  standards.    Many  of  the  protocols  use  standard  ASCII
commands.  This makes it easy  to  watch  what  is  going  on  and  to
diagnose  problems.  For example, the mail program keeps a log of each
conversation.  If something goes wrong, the log  file  can  simply  be
mailed  to  the  postmaster.  Since it is normal text, he can see what
was going on.  It also allows a human to interact  directly  with  the
mail  server,  for  testing.  (Some newer protocols are complex enough
that this is not practical.  The commands would have to have a  syntax
that would require a significant parser.  Thus there is a tendency for
newer protocols to use binary formats.  Generally they are  structured
like  C or Pascal record structures.)  Second, note that the responses
all begin with numbers.  This is also typical of  Internet  protocols.
The  allowable  responses  are  defined  in the protocol.  The numbers
allow the user program to respond unambiguously.    The  rest  of  the
response  is  text,  which is normally for use by any human who may be
watching or looking at a log.  It has no effect on  the  operation  of
the  programs.  (However there is one point at which the protocol uses
part of the text of the response.)   The  commands  themselves  simply
allow  the  mail  program  on  one  end  to  tell  the mail server the
                                  16
 


information it needs to know in order to deliver the message.  In this
case,  the  mail  server  could  get the information by looking at the
message itself.  But for more complex cases, that would not  be  safe.
Every  session  must  begin  with  a HELO, which gives the name of the
system that initiated the connection.  Then the sender and  recipients
are specified.  (There can be more than one RCPT command, if there are
several recipients.)  Finally the data itself is sent.  Note that  the
text  of the message is terminated by a line containing just a period.
(If such a line appears in the message, the period is doubled.)  After
the  message  is  accepted,  the  sender  can send another message, or
terminate the session as in the example above.

Generally, there is a pattern to the response numbers.   The  protocol
defines  the  specific set of responses that can be sent as answers to
any given command.  However programs that don't want to  analyze  them
in  detail  can  just  look at the first digit.  In general, responses
that begin with a 2  indicate  success.    Those  that  begin  with  3
indicate  that some further action is needed, as shown above.  4 and 5
indicate errors.  4 is a "temporary" error, such as  a  disk  filling.
The  message should be saved, and tried again later.  5 is a permanent
error, such as a  non-existent  recipient.    The  message  should  be
returned to the sender with an error message.

(For  more  details about the protocols mentioned in this section, see
RFC's 821/822 for mail, RFC 959 for file transfer, and  RFC's  854/855
for  remote  logins.  For the well-known port numbers, see the current
edition of Assigned Numbers, and possibly RFC 814.)



4. 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 datagrams, and
reassembling them properly.  However in  many  applications,  we  have
messages  that  will  always  fit in a single datagram.  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
datagram.    So  will the answer.  Thus it seems silly to use TCP.  Of
course TCP does more than just break things up  into  datagrams.    It
also  makes  sure  that  the  data  arrives, resending datagrams where
necessary.  But for a question that fits  in  a  single  datagram,  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
datagrams  together.  It fits into the system much like TCP.  There is
                                  17
 


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 datagrams.  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, RFC 882, and RFC 883), 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
RFC 792 for details of ICMP.  ICMP is  similar  to  UDP,  in  that  it
handles messages that fit in one datagram.  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.



5. Keeping track of names and information: the domain system


As we indicated earlier, the network software generally needs a 32-bit
Internet  address  in  order  to open a connection or send a datagram.
However users prefer to deal with computer names rather than  numbers.
Thus  there  is  a database that allows the software to look up a name
and find the corresponding number.  When the Internet was small,  this
was  easy.  Each system would have a file that listed all of the other
systems, giving both their name and number.  There are  now  too  many
computers  for  this  approach to be practical.  Thus these files have
been replaced by a set of name servers that keep track of  host  names
and  the corresponding Internet addresses.  (In fact these servers are
somewhat more general than that.  This is just one kind of information
stored in the domain system.)  Note that a set of interlocking servers
are used, rather than a single central one.  There  are  now  so  many
different  institutions  connected  to  the  Internet that it would be
impractical for them to  notify  a  central  authority  whenever  they
installed  or moved a computer.  Thus naming authority is delegated to
individual institutions.  The name servers form a tree,  corresponding
to  institutional  structure.    The names themselves follow a similar
structure.  A typical example is the name BORAX.LCS.MIT.EDU.  This  is
a  computer  at  the Laboratory for Computer Science (LCS) at MIT.  In
order to find its Internet address,  you  might  potentially  have  to
consult  4  different  servers.  First, you would ask a central server
                                  18
 


(called the root) where the EDU server is.  EDU is a server that keeps
track of educational institutions.  The root server would give you the
names and Internet addresses of several servers for EDU.   (There  are
several  servers  at  each  level,  to allow for the possibly that one
might be down.)  You would then ask EDU where the server for  MIT  is.
Again,  it  would  give  you  names  and Internet addresses of several
servers for MIT.  Generally, not all of those servers would be at MIT,
to  allow for the possibility of a general power failure at MIT.  Then
you would ask MIT where the server for LCS is, and finally  you  would
ask one of the LCS servers about BORAX.  The final result would be the
Internet address for BORAX.LCS.MIT.EDU.    Each  of  these  levels  is
referred  to  as  a  "domain".  The entire name, BORAX.LCS.MIT.EDU, is
called a "domain name".    (So  are  the  names  of  the  higher-level
domains, such as LCS.MIT.EDU, MIT.EDU, and EDU.)

Fortunately,  you  don't really have to go through all of this most of
the time.  First of all, the root name servers also happen to  be  the
name  servers  for  the  top-level domains such as EDU.  Thus a single
query to a root  server  will  get  you  to  MIT.    Second,  software
generally  remembers answers that it got before.  So once we look up a
name at LCS.MIT.EDU, our software remembers where to find servers  for
LCS.MIT.EDU,  MIT.EDU,  and EDU.  It also remembers the translation of
BORAX.LCS.MIT.EDU.  Each of these pieces of information has a "time to
live"  associated with it.  Typically this is a few days.  After that,
the information expires and has to be looked up again.    This  allows
institutions to change things.

The  domain  system  is not limited to finding out Internet addresses.
Each domain name is a node in a database.  The node can  have  records
that  define  a number of different properties.  Examples are Internet
address, computer type, and a list of services provided by a computer.
A  program  can  ask  for  a  specific  piece  of  information, or all
information about a given name.  It is possible  for  a  node  in  the
database  to  be  marked as an "alias" (or nickname) for another node.
It is also possible to use the  domain  system  to  store  information
about users, mailing lists, or other objects.

There  is  an  Internet  standard  defining  the  operation  of  these
databases, as well as the protocols used  to  make  queries  of  them.
Every  network utility has to be able to make such queries, since this
is now the official way to evaluate host names.   Generally  utilities
will talk to a server on their own system.  This server will take care
of contacting the other servers for them.  This keeps down the  amount
of code that has to be in each application program.

The  domain  system  is  particularly  important for handling computer
mail.  There are entry types to define what computer handles mail  for
a  given  name, to specify where an individual is to receive mail, and
to define mailing lists.

(See RFC's 882, 883, and 973 for specifications of the domain  system.
RFC 974 defines the use of the domain system in sending mail.)



                                  19
 


6. Routing


The   description  above  indicated  that  the  IP  implementation  is
responsible for getting datagrams 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  datagram  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 datagrams 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 datagram  out  on  the
Ethernet.)    The  problem  comes  when  a  system  is asked to send a
datagram 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 datagrams from one network to the
other.  That is, if a machine on network 128.6.4 sends a  datagram  to
the  gateway,  and  the  datagram is addressed to a machine on network
128.6.3, the gateway will forward the  datagram  to  the  destination.
Major communications centers often have gateways that connect a number
of different  networks.    (In  many  cases,  special-purpose  gateway
systems provide better performance or reliability than general-purpose
systems acting as gateways.  A number of vendors sell such systems.)

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 datagram, it first checks  to  see  if
the  destination address is on the system's own local network.  If so,
the datagram can be sent directly.  Otherwise, the system  expects  to
find an entry for the network that the destination address is on.  The
datagram 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.
                                  20
 


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  datagram,  the
datagram  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
RFC  792.)  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
datagram  to  MIT?    MIT  is  network 18.  Since we have no entry for
network 18, the datagram will be sent to the default, 128.6.4.59.   As
it  happens,  this  gateway  is the wrong one.  So it will forward the
datagram 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 datagrams to  MIT  will
then  go  directly to 128.6.4.1.  (The error message is sent using the
ICMP protocol.  The message type is called "ICMP redirect.")

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.  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.   RFC  1009  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.



7. Details about Internet addresses: subnets and broadcasting


As  indicated earlier, 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
                                  21
 


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 "subnets".  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 treat all datagrams addressed to 128.6 the same way.  They would
not look at the third octet of the address.   Thus  computers  outside
Rutgers  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 RFC 950.

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.  For example, 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 nearest name server.  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  datagrams
individually  to  each host that is interested in the information.  In
                                  22
 


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 datagram.

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.    Such  implementations  would  use  128.6.4.0  instead   of
128.6.4.255  as  the  broadcast  address on network 128.6.4.  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.



8. Datagram fragmentation 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
datagram  size.  When a TCP connection first opens, both ends can send
the maximum datagram 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 datagrams 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
                                  23
 


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  datagrams.    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   datagrams   up   into   pieces.    (This  is  referred  to  as
"fragmentation".)  The IP header  contains  fields  indicating  the  a
datagram  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  host
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
datagram  size.    It  is  fairly  common  for  implementations to use
576-byte datagrams whenever they can't verify that the entire path  is
able  to  handle larger packets.  This rather conservative strategy is
used because of the number of implementations with bugs in the code to
reassemble  fragments.    Implementors  often try to avoid ever having
fragmentation occur.  Different implementors take different approaches
to  deciding  when  it  is safe to use large datagrams.  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.



9. Ethernet encapsulation: ARP


There was a brief discussion earlier about what IP datagrams look 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 datagrams  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
                                  24
 


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 directly 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.



10. 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  used  to  be  a  separate  classification  for  more  informal
documents.  This classification no longer exists -- RFC's are now used
for  all  official  Internet documents, and a mailing list is used for
more informal reports.)  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

                                  25
 


     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.

     rfc1001/2 netBIOS: networking for PC's

     rfc973    update on domains

     rfc959    FTP (file transfer)

     rfc950    subnets

     rfc937    POP2: protocol for reading mail on PC's

     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
                                  26
 


               philosophy behind TCP/IP 

The following documents are somewhat more specialized.

     rfc813    window and acknowledgement strategies in TCP

     rfc815    datagram 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 and related issues 

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.





                                  27

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Jul-87 08:53:26 EDT
From:      jon@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Asyncio on Sockets

I know this is a Unix question and not really appropriate here,
but Berkeley and Sun people seem to read this list a lot.

Has anyone found problems setting async io on a RAW IP socket?
Under 3.2 on a Sun, it just doesn't seem to work; at least I
never get a SIGIO even when I see packets (using a net wathcer)
arriving at the machine. The manual pages and tutorials are somewhat
thin in this area.

Also, when using asyncio on a UDP socket, the process doesn't
get a SIGIO unless it has had another signal first.

Jon

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Jul 87 13:19:12 -0400
From:      Mike Brescia <brescia%ccv.bbn.com@CCV.BBN.COM>
To:        Mills@LOUIE.UDEL.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, ineng-tf@VENERA.ISI.EDU, nsfnet@SH.CS.NET, brescia@CCV.BBN.COM
Subject:   Re: Chrenobyl revisited

Beginning sometime on Tuesday, apparent (very real, in fact) meltdown of
routing seems to have been caused by:

1. frequent making and breaking of egp neighbor connections, due to

2. frangible egp neighbor-alive procedures or parameters, shattered by

3. long queues (or short queues and many dropped packets) on interfaces
connected to the arpanet, because of

4. changes in arpanet topology and delay characteristics.


Each change in neighborliness leads to routing changes in EGP which propogate
at one hop per 2(?) minutes, and in GGP (the core routing) cause burgeoning of
traffic as the protocol scurries to get the routing settled again.

The core gateways were being rejected (EGP cease message sent) by many of the
neighbors on the arpanet, and then later acquired again.  This may have been
caused by long queues on the sending end toward the core gateway, or by the
long queues frequently observed in the core gateways.

Thursday afternoon, the arpanet problem was cleared up.  I think the routing
explosion has settled to a dull roar after that.

I expect that the arpanet analysts will have a description of the problem and
its solution after the holiday.

    Mike Brescia
    (Gateway group)
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Jul-87 11:35:01 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Chrenobyl revisited

Peter,

Welcome to the swamps. If your gateway is peeping EGP with the core, you
will see a lot of this. The stuff I see sloshing by linkabit-gw is
truly awsome and includes many instances like yours. Even after I
disabled all reachability to all nets from that gateway for several
hours various hosts and gateways continued to route traffic for
j-random nets via it. Not knowing whether the senders were hosts or
gateways, linkabit-gw spat back redirects, but few seemed to believe
them (probably gateways masked in host clothing). In spite of the
fact the core gateways (for the moment) correctly reveal the routes
for that gateway, about two packets per second averaged throughout the
day are being routed incorrectly to linkabit-gw. See what you might
be in for?

Dave

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Jul-87 13:53:59 EDT
From:      brescia@CCV.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Chrenobyl revisited


Beginning sometime on Tuesday, apparent (very real, in fact) meltdown of
routing seems to have been caused by:

1. frequent making and breaking of egp neighbor connections, due to

2. frangible egp neighbor-alive procedures or parameters, shattered by

3. long queues (or short queues and many dropped packets) on interfaces
connected to the arpanet, because of

4. changes in arpanet topology and delay characteristics.


Each change in neighborliness leads to routing changes in EGP which propogate
at one hop per 2(?) minutes, and in GGP (the core routing) cause burgeoning of
traffic as the protocol scurries to get the routing settled again.

The core gateways were being rejected (EGP cease message sent) by many of the
neighbors on the arpanet, and then later acquired again.  This may have been
caused by long queues on the sending end toward the core gateway, or by the
long queues frequently observed in the core gateways.

Thursday afternoon, the arpanet problem was cleared up.  I think the routing
explosion has settled to a dull roar after that.

I expect that the arpanet analysts will have a description of the problem and
its solution after the holiday.

    Mike Brescia
    (Gateway group)

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Jul-87 15:15:27 EDT
From:      mel1@houxa.UUCP (M.HAAS)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Smart Ethernet boards

I think there are two performance factors to consider.  If one wants
to devote CPU cycles to Ethernet processing, then an off-board TCP/IP
makes sense and high network traffic rates can be achieved.  If the
CPU is already burdened by having to handle too many time-share users
or by just being too small, then an on-board TCP/IP makes sense (with
network traffic rates limited by the board/CPU combination's power).

If the on-board TCP/IP imposes more load on the CPU than an off-board
TCP/IP, then something is radically wrong with the design.  If anyone
has evidence of such a situation, please post it here so we can avoid
purchasing that board.

For small systems with 80386 and 68020 class CPUs, I would think that
an on-board TCP/IP with similar CPU and decent memory buffers would give
optimum performance.  Does anyone have figures or thoughts as to what
impedes performance?  One article here commented on the multiple
copies being made of the data being transferred.  Is that necessary
or desirable?  Couldn't the on-board TCP/IP processor just handle
the headers on the board and DMA the data to/from user's I/O space?
(i.e. no copying, just pointer shuffling)  Are there TCP/IP
implementations that do this?

   Mel Haas  ,  odyssey!mel

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jul-87 00:11:55 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Chrenobyl revisited

Mike,

I'm not sure I agree with your comment that the non-core EGP gateways are
terminating associations with the core gateways; in fact, I believe it's the
other way around. Following is a summary of data collected over a 36-hour
interval from old fuzzball EGP slugger dcn-gw, which ordinarily sustains
associations with all three core EGPspeakers ISI [10.3.0.27], BBN2 [10.7.0.63]
and PURDUE [10.2.0.37]. As specified in the initial dialog, the hello interval
is 60 seconds, while the poll interval is 180 seconds.

The table below shows the events and actions of the state machine for each
peer as specified in RFC-904. A Cease event represents a termination on the
part of the core gateway, while a Cease action represents a termination on the
part of dcn-gw, almost always as the result of an extended period when no
messages whatsoever have been received. As can be seen, the core gateway
terminates the association between two and four times as often as dcn-gw.

Hello interval	60
Poll interval	180
Neighbor ->	[10.3.0.27]	[10.7.0.63]	[10.2.0.37]
Tally		Event	Action	Event	Action	Event	Action
--------------------------------------------------------------
Request		0	65	0	8	0	36	
Confirm		29	0	5	0	19	0
Refuse		2	0	0	0	0	0
Cease		26	9	3	1	16	4
Cease-ack	4	26	1	3	2	16
Hello		0	2172	0	2284	0	2232
I-H-U		1568	0	1904	0	1735	0
Poll		699	609	829	741	750	667
Update		532	669	656	824	604	736
Down		221		52		123
Bad sequence	151		129		148

Note the rather high incidence of Down events. Using the j,k parameters
suggested in RFC-904 and the 60-second hello interval, a Down event would
occur if three out of four reachability indications during the last four
minutes were lost. This sounds rather extreme. Note also the rather high
incidence of Bad sequence events, which occur when a reply to a hello message
has incorrect sequence number and is discarded. There is a strong argument for
ignoring the sequence-number check, since the order of reachability events is
seldom meaningful. It may be useful in the present regime of positive network
void coefficents to do that to avoid further meltdown.

Dave

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jul-87 10:57:07 EDT
From:      randy@DBNET.CS.WASHINGTON.EDU (Randy Day)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options implementation

Been looking at this code in the last few days myself.

I've been looking at the 4.2BSD and 4.3BSD implementations of ip_output()
in /sys/netinet/ip_output.c.

As far as I can tell (and I feel fairly confident about this), the
4.2BSD code just ignores any options passed to the ip_output routine.

The 4.3 code replaces the initial call to m_free(opt) with
if (opt)
	m = ip_insertoptions(m, opt, &hlen);
Where ip_insertopitons() is a new function that does about what you
would expect: it inserts mbufs containing the options in the
data about to blasted out over the net.

The 4.3BSD "Changes to the Kernel in 4.3BSD" manual section says:
"Support was added for IP source routing and other IP options....IP properly
updates source-route and record-route options when forwarding (and leaves
them in the packet, unlike 4.2 which stripped them out after updating)."

The 4.2BSD networking code is brain damaged, and would certainly not
pass even the most modest validation suite if one existed for TCP/IP
implementations.

Randy Day.
Internet (ARPA): randy@dbnet.cs.washington.edu
CSNET: randy%washington@relay.cs.net
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jul-87 11:29:49 EDT
From:      van@LBL-CSAM.ARPA (Van Jacobson)
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.

The part of the security option ftp & telnet need is implemented
in 4.3.  User level programs can stick a security option on any
TCP, UDP or IP socket.  The option will be tacked onto every IP
datagram sent on that socket.  The code to do this looks
something like

	/* format a legal security option in a 12 byte array */
	ipopt[IPOPT_OPTVAL] = IPOPT_SECURITY;
	ipopt[IPOPT_OLEN] = 11;
	...
	ipopt[11] = IPOPT_NOP;	/* pad */

	/* put the option on socket "s" */
	if (setsockopt(s, IPPROTO_IP, IP_OPTIONS, ipopt, 12) < 0)
		perror ("setsockopt:ipopt:");

On the incoming side, 4.3 ip ignores the security option and 4.3
tcp discards it.  But the option is passed intact up to the tcp
layer and it would be trivial to change tcp_input to process it
(If you were trying to make a secure Unix, you'd be re-writing
the kernel.  This change would be the least of your worries and,
anyway, it couldn't be done until the rest of the system security
model was in place.)

 - Van

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jul-87 11:46:42 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: connection establish timeout query

Mike and David,  You are asking a question that covers many sins.
The usual numbers for "open connection" timeouts range from 30-120
seconds.  If you are using numbers much smaller than these you
wil see lots of timeouts.  The problem of selcting the "right"
timeout is a bit complex because of what you (the initiator)
might be trying to accomplish.  E.g.,  if it is a Telnet session
then the user is a human and can abort the (presumably hopeless)
connection attempt by some local action (escape character or its
functional equivalent on each system -- if you don't have the
equivalent of an "interrupt now" initiated by the user from
the keyboard, then...) so you may as well select a long timeout
(2 minutes) and let the connection get established if at all 
possible.  The same goes for FTP because it is user initiated.

However, for mail (SMTP) things can get different.  It is usually
implemented as a background process that slurps over the file
system looking for mail files to send out.  If this SMTP process
uses a long timeout and it runs into a bunch of mail for a dead
site it has to get smart about what is (not) happening and not spend
a lot of time waiting for a connection to the dead host.  Thus a
short timeout (30 seconds) might be in order.  Big systems that
do lots of mail have had to take more hurculean efforts in this
arena, like running a number of SMTP mail processes in parallel
and having some scheme for staying out of each other's way...

The reason for along timeout can lie with many sources:  the local host
might not have a good retransmission timout for the original
"open packet", the network(s) may be congested, or the remote
host may take some time to set up a process to respond to the
open request.

Anyway,  the major crime is to have client programs choosing
a timeout that is smaller than the retransmission timeout
that the TCP is using to detect a lost packet and try the open SYN again.

Dan
-------

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1987 11:46:42 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Mike Brescia <brescia%ccv.bbn.com@CCV.BBN.COM>
Cc:        tcp-ip@SRI-NIC.ARPA, kirschen%multimax.arpa@CCV.BBN.COM, LYNCH@A.ISI.EDU
Subject:   Re: connection establish timeout query
Mike and David,  You are asking a question that covers many sins.
The usual numbers for "open connection" timeouts range from 30-120
seconds.  If you are using numbers much smaller than these you
wil see lots of timeouts.  The problem of selcting the "right"
timeout is a bit complex because of what you (the initiator)
might be trying to accomplish.  E.g.,  if it is a Telnet session
then the user is a human and can abort the (presumably hopeless)
connection attempt by some local action (escape character or its
functional equivalent on each system -- if you don't have the
equivalent of an "interrupt now" initiated by the user from
the keyboard, then...) so you may as well select a long timeout
(2 minutes) and let the connection get established if at all 
possible.  The same goes for FTP because it is user initiated.

However, for mail (SMTP) things can get different.  It is usually
implemented as a background process that slurps over the file
system looking for mail files to send out.  If this SMTP process
uses a long timeout and it runs into a bunch of mail for a dead
site it has to get smart about what is (not) happening and not spend
a lot of time waiting for a connection to the dead host.  Thus a
short timeout (30 seconds) might be in order.  Big systems that
do lots of mail have had to take more hurculean efforts in this
arena, like running a number of SMTP mail processes in parallel
and having some scheme for staying out of each other's way...

The reason for along timeout can lie with many sources:  the local host
might not have a good retransmission timout for the original
"open packet", the network(s) may be congested, or the remote
host may take some time to set up a process to respond to the
open request.

Anyway,  the major crime is to have client programs choosing
a timeout that is smaller than the retransmission timeout
that the TCP is using to detect a lost packet and try the open SYN again.

Dan
-------
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jul-87 15:47:45 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options implementation

Because nobody at the time had any idea what you would use the security
option for.

-R
	t

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jul-87 21:27:49 EDT
From:      brescia@CCV.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   connection establish timeout query


I would interpret this question as "What should the open timeout be for
telnet, ftp, and mail user and server programs?" What sort of numbers are used
in the software?

    mike

---- forwarded message ----

Received:  by multimax.ARPA (4.12/25-eef)
	id AA02553; Wed, 1 Jul 87 09:02:23 edt
Date: Wed, 1 Jul 87 09:02:23 edt
From: David Kirschen <kirschen@multimax.ARPA>
Message-Id: <8707011302.AA02553@multimax.ARPA>
Subject: Arpanet Timeouts

Hi - Could you tell me if there is a way to determine if we are
seeing a reasonable number of connection timeouts over the Arpanet?
We get lots of connections failing, for various applications (mail, ftp,
telnet).  We'd like to know what the commonly used  timeout constant
is (i.e., how long should it take when establishing a connection before
the initiator just gives up?).  Thanks !!

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jul-87 22:57:44 EDT
From:      gkn@SDS.SDSC.EDU
To:        comp.protocols.tcp-ip
Subject:   RE: Mac/Ip


	From:	 Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
	Subject: Mac/Ip
	Date:	 Thu, 25 Jun 87 10:34:42 P
 
	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?
 
The version of MAC-IP I have supports ethernet communications through one
of two boxes manufactured by Kinetics in Walnut Creek.  The first (and older)
of these two boxes is called the FastPath, and is capable of acting as bridge
between Appletalk and ethernet.  It can operate in a pure-Appletalk mode,
or it can operate in a combined Appletalk and "user datagram" mode, which lets
it carry IP.  One FastPath can serve several MACs connected to an Appletalk
network.

The second box is called the EtherSC, and connects a MAC directly up to
thinwire ethernet via the SCSI port.  So far I only have it carrying IP
traffic.  There is one EtherSC per MAC, and the EtherSC is considerably
cheaper than the FastPath.

The heritage of the TCP code I'm using is a bit fuzzy, so I'm reluctant
to comment on it for fear of being wrong.  However, there is an excellent
TELNET/FTP server program available from NCSA (National Center for
Supercomputing Applications) at the University of Illinois.  Contact Gaige
Paulson there for more information.  There's no SMTP support that I'm
aware of ... but if anyone knows of something I'd sure like to hear about
it.

gkn
--------------------------------------
Arpa:	GKN@SDS.SDSC.EDU
Bitnet:	GKN@SDSC
Span:	SDSC::GKN (27.1)
USPS:	Gerard K. Newman
	San Diego Supercomputer Center
	P.O. Box 85608
	San Diego, CA 92138
AT&T:	619.534.5076

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Jul-87 23:31:13 EDT
From:      gnu@hoptoad.uucp (John Gilmore)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options implementation

tucker%mycroft@gswd-vms.Gould.COM (Tim Tucker) wrote:
> 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.

I have an idea -- why doesn't Gould implement it, and post the changes
to the net, or send them to Berkeley?  You seem to be the first to need
it, and making it available for free, like Berkeley did with the whole
protocol implementation, makes it likely that "a common implementation
across all users" will exist.
-- 
{dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu	       gnu@ingres.berkeley.edu
Alt.all: the alternative radio of the Usenet. Contributions welcome - post 'em

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Jul-87 00:19:23 EDT
From:      mouse@mcgill-vision.UUCP (der Mouse)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Serial Line IP and ULTRIX-32 2.0

In article <1358@decuac.DEC.COM>, avolio@decuac.dec.com (Fred Avolio) writes:
> In article <662@moogvax.UUCP>, dave@moogvax.UUCP (Dave Szczepanski) writes:
>> [I]s it possible to install [SLIP] if you are binary site. 
 
> I see no easy way to install it with a binary kit since you need to
> modify init_main,

Fortunately it *is* possible.  It is not especially easy, and it is a
dreadful hack, but until we manage to stamp out binary distributions
this trick may come in handy to someone.

What we do is to patch the "_loattach" symbol in the init_main.o symbol
table to something like "_F_Avolio" (Hi Fred!) and then configure in a
file containing something like the following (or add it to an existing
file we have source to):

F_Avolio()
{
 do_whatever_we_want();
 loattach();
}

(Why F_Avolio?  No particular reason.  You can use derMouse if you'd
rather - Fred might even prefer you did :-).  Anything the same length
as "loattach" will do perfectly well, provided it doesn't conflict with
anything already present in the kernel.)

How do we patch the symbol table?  Assuming a normal Ultrix system,

# strings - -o init_main.o | egrep _loattach
    1234      _loattach
# adb -w init_main.o init_main.o
0t1234/S
4d2:		_loattach
.+1/W 'vA_F'
4d3:		74616f6c	= 76415f46
0t1234/S
4d2:		_F_Avtach
.+5/W 'oilo'
4d7:		68636174	= 6f696c6f
0t1234/S
4d2:		_F_Avolio
$q
#

We give adb the file name twice so we can use the offset strings gave
us:  since the file is an a.out, adb does address mapping for a.outs,
which is good in general, but doesn't help here, so we get around by
giving the filename twice and using the / forms of the examine and
deposit commands.  You can also do this by using $m and a little
arithmetic, but it's much simpler to just do the above.  It works
because the .o file is not a valid core image, so adb doesn't do its
address mapping for the / command forms.  (F_Av and olio are spelled
backwards because adb is too dumb to fix the order of the characters in
'xxxx' constants.)

If you do try this, I MOST STRONGLY urge you to keep backup copies of
EVERYTHING you touch!

					der Mouse

				(mouse@mcgill-vision.uucp)

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1987 05:44-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        van@LBL-CSAM.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: IP options implementation
For  single  level systems (those evaluated at less than B2), the
only place you need to deal with the IP security option is at the
IP  level.   You need to have a configuration item which sets the
level of your system.  This must be  reflected  in  the  outgoing
packets,  and  muct  also  be  checked  in the incomoing packets.
Incoming packets without the proper security option in them  must
be logged and dropped.

(Err,  this  is what the rules say, if I were imple,menting this,
I'd add a configuration item for dropping non-compliant  incoming
datagrams  and  leave it off until you connect to BLACKER, or are
reasonably certain everyone else is in compliance.)

By the way, which  IP  security  option  is  everyone  out  there
concerned  about?   The  one  in the RFC?  If so, hang on to your
horses.  You might want to take a look at  the  revised  IPSO  in
[NIC]ps:<stjohns>ipso.txt.

Mike
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 08:44:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: IP options implementation

For  single  level systems (those evaluated at less than B2), the
only place you need to deal with the IP security option is at the
IP  level.   You need to have a configuration item which sets the
level of your system.  This must be  reflected  in  the  outgoing
packets,  and  muct  also  be  checked  in the incomoing packets.
Incoming packets without the proper security option in them  must
be logged and dropped.

(Err,  this  is what the rules say, if I were imple,menting this,
I'd add a configuration item for dropping non-compliant  incoming
datagrams  and  leave it off until you connect to BLACKER, or are
reasonably certain everyone else is in compliance.)

By the way, which  IP  security  option  is  everyone  out  there
concerned  about?   The  one  in the RFC?  If so, hang on to your
horses.  You might want to take a look at  the  revised  IPSO  in
[NIC]ps:<stjohns>ipso.txt.

Mike

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 08:52:39 EDT
From:      mrose@GREMLIN.NRTC.NORTHROP.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: status of POP


    Well, being Marshall T. Rose, I guess I should respond.  There are
    several POP protocols.  As to which one is the official one, that's
    a good question.

    The original POP was done at USC/ISI.  The people working on MH
    liked this quite a bit but weren't able to quite implement it, so I
    did an alternate service/protocol specification and put that in MH.
    Shortly thereafter, USC/ISI came out with POP2, which pretty much
    fixed all the problems in the original POP.  For reasons not worth
    going into, MH's POP and ISI's POP2 never merged, so future POP work
    in MH used MH's POP.  This future work included support for remote
    BBoards (which you can also get with NNTP, I think) and support for
    Stanford's version of MH for the PC.  

    About 10 months ago, the parties involved were supposed to get
    together and solve this problem (multiple versions), but we never
    got around to it.  Hence the current situation.  

    The question as to which version is official and which version(s)
    are useful, being widely implemented, is problematic.  The original
    POP is history.  That leaves POP2 and MH's POP.

/mtr

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 08:58:49 EDT
From:      kirschen@MULTIMAX.ARPA (David Kirschen)
To:        comp.protocols.tcp-ip
Subject:   connection establish timeout query


   Date: Thu, 02 Jul 87 11:53:33 -0400
   From: Mike Brescia <brescia%ccv.bbn.com@CCV.BBN.COM>

Mike, thanks for getting back to me.  I'm not sure what timeout values we
are currently using here - that's why I asked the question.  Do you have a
feel for what is "common" around the Arpanet ?  I would expect that about
the same timeout limits are used almost everywhere, and I'd like to know
what those values are.  We understand that the timeout's are determined by
the software, and we just want to see if we are "in the ballpark" compared
to other sites.  Thanks again!

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

   I would interpret this question as "What should the open timeout be for
   telnet, ftp, and mail user and server programs?" What sort of numbers are
   used in the software?

       mike

   ---- forwarded message ----

   Received:  by multimax.ARPA (4.12/25-eef)
	   id AA02553; Wed, 1 Jul 87 09:02:23 edt
   Date: Wed, 1 Jul 87 09:02:23 edt
   From: David Kirschen <kirschen@multimax.ARPA>
   Message-Id: <8707011302.AA02553@multimax.ARPA>
   Subject: Arpanet Timeouts

   Hi - Could you tell me if there is a way to determine if we are
   seeing a reasonable number of connection timeouts over the Arpanet?
   We get lots of connections failing, for various applications (mail, ftp,
   telnet).  We'd like to know what the commonly used  timeout constant
   is (i.e., how long should it take when establishing a connection before
   the initiator just gives up?).  Thanks !!

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jul 87 12:19 PDT
From:      Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: DECnet-TCP/IP gateway
> Looking for gateway software, preferably layered atop Wollongong,
> for a MicroVax.  In and out via shared DEQNA.
> Mail is the biggest need.  FTP strongly desired.  Telnet desired,
> but let's be realistic.
>        Charles Bacon, CRB@NIHCUDEC (bitnet)

As far as mail goes, you could run the PMDF mail system which supports
Wollongong and DECnet channels (also bitnet, phonenet, and others).  Contact
Ned Freed at Harvey Mudd College for more info (714) 621-8006.

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jul 1987 11:52:47 LCL
From:      John M. Wobus <JMWOBUS%SUVM.BITNET@wiscvm.wisc.edu>
To:        IBM-NETS@BITNIC, TCP-IP Discussion Group <TCP-IP@SRI-NIC.ARPA>, Monthly guide to BITNET Servers and Services <BITLIB@YALEVM>, IBM7171@MARIST, Proteon P4200 Gateway Discussion <P4200@DEVVAX.TN.CORNELL.EDU>, INFO-PROTEON@UXC.CSO.UIUC.EDU
Subject:   New mailing list.
I am starting a new mailing list on LAN issues for large campus networks
(e.g. multiprotocol, multivendor, etc).  See blurb below.  Please excuse
this message if you've already received it through another list.

John Wobus
Syracuse University

-------------------------------
BIG-LAN@SUVM                             (Bitnet)
<BIG-LAN%SUVM.BITNET@WISCVM.WISC.EDU>    (Internet)

   This list is for the discussion of issues in designing and
   operating Campus-Size Local Area Networks, especially complex
   ones utilizing multiple technologies and supporting multiple
   protocols.  Topics include repeaters, bridges, routers and
   gateways; how to incorporate smaller Personal-Computer type LANs
   into the campus-wide LAN; how to unify the mail systems, etc.
   This is an ideal list in which to debate the relative merits of
   bridges vs routers.

   All requests to be added to or deleted from this list, problems,
   questions, etc., should be sent to BIG-REQ@SUVM (Bitnet) or
   <BIG-REQ%SUVM.BITNET@WISCVM.WISC.EDU> (Internet).  Those familiar
   with revised LISTSERV can subscribe with LISTSERV@SUVM (Bitnet)
   or <LISTSERV%SUVM.BITNET@WISCVM.WISC.EDU> (Internet).

   Archives are available through revised LISTSERV.

   Coordinator: John Wobus <JMWOBUS@SUVM>
                           <JMWOBUS@SUVM.BITNET%WISCVM.WISC.EDU>
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 87 14:19:00 MST
From:      "HOLT JC SSGT DOASS 32254" <holtj@afsc-sd.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Wollongong TALKING to DEC-20's
                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      6-Jul-1987 13:58 PST
                                        From:      Jack C. Holt, SSgt 
                                                   HOLTJ 
                                        Dept:      2080CS/DOAS
                                        Tel No:    643-2254

TO:  _MAILER!                             ( _DDN[MRC%PANDA.COM@SUMEX-AIM.STANFORD.EDU] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )

CC:  TSgt Thomas                          ( THOMASJR )
CC:  Communications Administration        ( COMADM )
CC:  DANAHY, DANIEL J.                    ( DANAHY )

Subject: Wollongong "talking" to DEC-20's

    This is in reference to your message to TCP-IP@SRI-NIC.arpa on 
6 July 87 concerning the subject.

    Could you be more specific about some of the problems people 
are having?

    We have also experienced problems talking to at least some 
DEC-20's and are running Wollongong's WIN/TCP version 3.0 on a 
VAX 11/785.

    We have unexplained instances of undeliverable mail when trying 
to send mail to SRI-NIC.arpa and GUNTER-ADAM.arpa.  We are also 
experiencing "Connection Refused..." errors when using GETTABLE to 
retrieve the HOST table from SRI-NIC.arpa.

------
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 11:40:32 EDT
From:      daveb@geac.UUCP (Dave Brown)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Smart Ethernet boards

In article <585@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes:
>For small systems with 80386 and 68020 class CPUs, I would think that
>an on-board TCP/IP with similar CPU and decent memory buffers would give
>optimum performance.  Does anyone have figures or thoughts as to what
>impedes performance?  One article here commented on the multiple
>copies being made of the data being transferred.  Is that necessary
>or desirable?  Couldn't the on-board TCP/IP processor just handle
>the headers on the board and DMA the data to/from user's I/O space?
>
>   Mel Haas  ,  odyssey!mel

  A side point that might be of interest here: "an on-board TCP/IP with 
similar CPU and decent memory buffers would give optimum performance"
implies that the TCP/IP board could be programmed from the host. If you
have the choice of such a board, go for it.

  CP-6 (and possibly CP-V) has a mechanism for compiling parts of
major programs (like editors) to run on the front-end processors.  As
a result the front ends tended to be accesable, programmable in
something other than assembler and maintainable.
  A performance improvement was there too: the two parts of the "same"
program tended to know how to communicate with each other effectively,
using the basic comms primitives the system provided. Especially minimizing
redundant copying.

  So look for boards with big ram buffers and hooks for user
programmability/downloading: you may bless your foresight.
-- 
 David (Collier-) Brown.              |  Computer Science
 Geac Computers International Inc.,   |  loses its memory
 350 Steelcase Road,Markham, Ontario, |  (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 13:11:03 EDT
From:      JMWOBUS@SUVM.BITNET (John M. Wobus)
To:        comp.protocols.tcp-ip
Subject:   New mailing list.

I am starting a new mailing list on LAN issues for large campus networks
(e.g. multiprotocol, multivendor, etc).  See blurb below.  Please excuse
this message if you've already received it through another list.

John Wobus
Syracuse University

-------------------------------
BIG-LAN@SUVM                             (Bitnet)
<BIG-LAN%SUVM.BITNET@WISCVM.WISC.EDU>    (Internet)

   This list is for the discussion of issues in designing and
   operating Campus-Size Local Area Networks, especially complex
   ones utilizing multiple technologies and supporting multiple
   protocols.  Topics include repeaters, bridges, routers and
   gateways; how to incorporate smaller Personal-Computer type LANs
   into the campus-wide LAN; how to unify the mail systems, etc.
   This is an ideal list in which to debate the relative merits of
   bridges vs routers.

   All requests to be added to or deleted from this list, problems,
   questions, etc., should be sent to BIG-REQ@SUVM (Bitnet) or
   <BIG-REQ%SUVM.BITNET@WISCVM.WISC.EDU> (Internet).  Those familiar
   with revised LISTSERV can subscribe with LISTSERV@SUVM (Bitnet)
   or <LISTSERV%SUVM.BITNET@WISCVM.WISC.EDU> (Internet).

   Archives are available through revised LISTSERV.

   Coordinator: John Wobus <JMWOBUS@SUVM>
                           <JMWOBUS@SUVM.BITNET%WISCVM.WISC.EDU>

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 13:55:37 EDT
From:      MRC@PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Wollongong TCP/IP for VAX/VMS


     I received my nth bug report from a Wollongong site today complaining
that mail didn't work between them and a DEC-20.  This is a ritual that I
end up undergoing multiple times a week.

     The problem is, of course, that the Wollongong software simply does
not work (even its original author, who is now behind a competing software
package, admits it) and that Wollongong simply does not care.

     I would like to see a policy statement forbidding US government sites
from wasting any more taxpayers' money on Wollongong software, and some
note from the NIC to that effect in the TCP/IP Vendors List.  Since
Wollongong presumably does care about its revenue, this might induce them
to fix the bugs...or go out of business, an equally acceptable alternative.

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

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 14:23:44 EDT
From:      titley@btnix.axion.bt.co.uk (Nigel Titley)
To:        comp.protocols.tcp-ip
Subject:   Excelan tcp-ip hangs on System V (NUXI)

We run a  small network  of miscellaneous  machines, mostly  Vaxen (VMS  and
UNIX)  but  some  SUNS, MG1s,  Bleasdales etc.  We decided  sometime ago  to
standardize on TCP/IP as our networking protocol, and on the Excelan product
as the interface on all our Vaxen. On all machines except the two 750s and a
microVax II running NUXI (The Instruction Set's version of System V) we have
no problems at all. However on these machines we have  problems with  tcp/ip
connections hanging.

Excelan don't want to know because we are not running standard System V  and
the NUXI driver is  not supported  by them.  Inset have  fiddled around  for
several months and say it is something to do with the Excelan firmware. They
also say that it is something that occurs with `standard' System V as  well,
which Excelan will not admit.

Has anyone else had this sort of  problem with  the Excelan  product? If  so
please let me know and perhaps I can beat Excelan  round the  head with  it?
Even better, if someone knows  what causes  the problem  or has  a fix  then
please, please let me know.

I've just had the final note from Inset saying  that they  are dropping  the
problem, and I'm feeling desparate.


-- 
Email: NTitley@axion.bt.co.uk
Snail: British Telecom Research labs, Martlesham Heath, Ipswich, Suffolk, UK

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 15:19:00 EDT
From:      KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso)
To:        comp.protocols.tcp-ip
Subject:   Re: DECnet-TCP/IP gateway

> Looking for gateway software, preferably layered atop Wollongong,
> for a MicroVax.  In and out via shared DEQNA.
> Mail is the biggest need.  FTP strongly desired.  Telnet desired,
> but let's be realistic.
>        Charles Bacon, CRB@NIHCUDEC (bitnet)

As far as mail goes, you could run the PMDF mail system which supports
Wollongong and DECnet channels (also bitnet, phonenet, and others).  Contact
Ned Freed at Harvey Mudd College for more info (714) 621-8006.

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 17:19:00 EDT
From:      holtj@AFSC-SD.ARPA ("HOLT JC SSGT DOASS 32254")
To:        comp.protocols.tcp-ip
Subject:   Wollongong TALKING to DEC-20's


                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      6-Jul-1987 13:58 PST
                                        From:      Jack C. Holt, SSgt 
                                                   HOLTJ 
                                        Dept:      2080CS/DOAS
                                        Tel No:    643-2254

TO:  _MAILER!                             ( _DDN[MRC%PANDA.COM@SUMEX-AIM.STANFORD.EDU] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )

CC:  TSgt Thomas                          ( THOMASJR )
CC:  Communications Administration        ( COMADM )
CC:  DANAHY, DANIEL J.                    ( DANAHY )

Subject: Wollongong "talking" to DEC-20's

    This is in reference to your message to TCP-IP@SRI-NIC.arpa on 
6 July 87 concerning the subject.

    Could you be more specific about some of the problems people 
are having?

    We have also experienced problems talking to at least some 
DEC-20's and are running Wollongong's WIN/TCP version 3.0 on a 
VAX 11/785.

    We have unexplained instances of undeliverable mail when trying 
to send mail to SRI-NIC.arpa and GUNTER-ADAM.arpa.  We are also 
experiencing "Connection Refused..." errors when using GETTABLE to 
retrieve the HOST table from SRI-NIC.arpa.

------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Jul-87 17:48:14 EDT
From:      ron@MANTA.NOSC.MIL (Ron Broersma)
To:        comp.protocols.tcp-ip
Subject:   Re: status of POP

It would be nice if someone decided what was the official version of POP.  We
assumed some time ago that the official version was POP2 because at the time
that was the latest POP protocol documented in an RFC.  I had the MH version but
it clearly didn't implement POP2 although it did some other things nicely.

We have our own PC mail implementation.  It uses POP2 because we like to
stick with standards and we thought POP2 was it.  If someone is going to
merge POP2 and MH-POP into POP3 and call it the standard, that would be
great.  However, I'd like a chance to have input because we have found POP2
to be deficient in a couple of minor ways and were required to modify it and
hence stray from the "standard", sigh.

--Ron

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Jul-87 00:45:58 EDT
From:      brady@MACOM4.ARPA (Sean Brady)
To:        comp.protocols.tcp-ip
Subject:   Re:  Asyncio on Sockets

In reference to your question, we are using asynch io through raw sockets 
on Sun3's (under release 3.2), and have had little problems getting things
going once the initial slugging is done. If you look in the documentation,
you will be hopelessly confused unless you take the time to play with it 
for a bit. 
This is how we set up a asynch io socket under suntools (another confusing
beast):
make_my_socket(proto)
int proto;
{
        int s;

        if ((s = socket(AF_INET, SOCK_RAW, proto)) < 0) {
                perror("socket");
        }
        fcntl(s, F_SETFL, FASYNC);
        fcntl(s, F_SETOWN, pktpid);
        (void) notify_set_input_func(frame, process, s);
        return(s);
}
where pktpid is the process id that is setting up the socket.

If you are outside the suntools environment, just substitute a

      signal(SIGIO,process);

for the notify_set_input_func(bla...bla), where process is your socket reader.

That should give you a live socket that interupts when a packet of type
"socket" arrives. You could then use the "recvfrom" call to read from
and the "sendto" call to write to the socket created.

Hope this helps...

		-Sean (He who Laughs, Lasts)
***********************************************************************
"Mistakes are often the stepping stones to utter failure."

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Jul-87 15:30:40 EDT
From:      weltyc@NIC.NYSER.NET (Christopher A. Welty)
To:        comp.protocols.tcp-ip
Subject:   Wollongong TCP/IP for VAX/VMS


	You might also tell DEC about it, since they sell TWG software
for VMS as the official VAX?VMS TCP/IP product.

---

Christopher Welty - Asst. Director, RPI CS Labs
weltyc@cs.rpi.edu       ...!seismo!rpics!weltyc

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Jul-87 18:51:39 EDT
From:      dennisw@iscuva.ISCS.COM (Dennis Weaver)
To:        comp.protocols.tcp-ip
Subject:   Request for info on public domain TCP-IP source

We are interested in locating "Public Domain" source of TCP-IP, FTP & TELNET
written in "C" (if such a thing exists).  Does anyone know where we can find
these sources  ???

Thanks in advance.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 87 08:45:00 PDT
From:      "ZEUS::HOLTJ" <holtj%zeus.decnet@afsc-sd.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   The fixing of problems with Wollongong WIN/TCP 3.0
                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      8-Jul-1987 07:41 PST
                                        From:      Jack C. Holt, SSgt 
                                                   HOLTJ 
                                        Dept:      2080CS/DOAS
                                        Tel No:    643-2254

TO:  _MAILER!                             ( _DDN[MRC%PANDA.COM@SUMEX-AIM.STANFORD.EDU] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )

CC:  TSgt Thomas                          ( THOMASJR )
CC:  Communications Administration        ( COMADM )
CC:  DANAHY, DANIEL J.                    ( DANAHY )

Subject: The fixing of problems with Wollongong WIN/TCP 3.0

    In following up the message which I sent yesterday in reply to 
Mark Crispin's message about the Wollongong to DEC20 interface:  I 
contacted Jerry Scott of Wollongong yesterday about our problems 
talking to DEC20's as well as other problems.  It appears that our 
problems with talking to SRI-NIC.arpa (a DEC20) were caused by an 
incorrect installation (gateways were properly set up).  

    After working with Mr. Scott things seem to have cleared up and 
we have been able to send several messages to SRI-NIC.arpa with no 
problems.
    
    Also, Mr. Scott showed a great deal of concern about solving 
our problems with mailer.

------
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Jul-87 10:09:42 EDT
From:      HANK@BARILVM.BITNET (Henry Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Israel Tcp/Ip Plans


                         Conversion Plans
                        from RSCS to Tcp/Ip
                    for Israel Academic Network

                                by
                         Henry Nussbacher
                          July 7th, 1987



Table of Contents
Acknowledgments

I.   Reasons for conversion
     A. Background
     B. Reasons
II.  Why Tcp/Ip and not something else?
     A. SNA
     B. DECNET
     C. ISO
     D. TCP/IP
     E. Caveats
III. What will it cost?
     A. Alternatives
        1. High speed LAN (Ethernet)
        2. BSC driver for leased lines
        3. Tcp/Ip "black" boxes
     B. VM
     C. MVS
     D. Unix
     E. VMS
     F. Primos
     G. NOS
     H. Intercampus
     I. Total cost for all systems
IV.  Timetable for conversion
     A. Stage I   - The test
     B. Stage II  - Tcp/Ip for everyone
     C. Stage III - The Tcp/Ip<->RSCS gateway
     D. Stage IV  - Conversion to ISO
V. Appendix 1 - List of Israeli EARN nodes
   Appendix 2 - Cost of connecting PC's to a Tcp/Ip Network
   Appendix 3 - List of Tcp/Ip software and hardware vendors
   Appendix 4 - The Tcp/Ip Reference Model
   Appendix 5 - Glossary of acronyms
   Appendix 6 - References
   Appendix 7 - EARN Migration Plans
   Appendix 8 - Israel viewpoint on EARN Migration Plans


Acknowledgements:

    Many people  have provided  valuable input  but there  are a few
whom I wish to single out:

John Klensin   - MIT
Mike Kramer    - Nynex
Scott Brim     - Cornell University
Marshall Rose  - Northrop Research
Dan Lynch      - ACE

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

I. REASONS FOR CONVERSION
   ======================

I.A: Background:

    This report is based on meetings held by the Israeli  University
Telecommunications  Subcommittee.   Various  pros  and  cons  of the
following proposal were  discussed and argued.   All members of  the
Telecommunications Subcommittee have reviewed this proposal and have
stated their views to me via electronic mail.

I.B: Reasons:

    Quite often people ask, "Why  do we need to change  something if
it works  perfectly and  gets the  job done  correctly?"  This  is a
valid question and  this section will  answer it.  Currently,  there
are 43 computers connected to the Israeli section of EARN  (European
Academic  Research  Network  -  sister  network of Bitnet).  The six
operating systems are:

VMS        14
Unix       11
VM          8
NOS         4
MVS         3
Primos      3
          ---
Total      43

    The protocol in use  today is known as  RSCS, also known as  NJE
(Network Job  Entry).  This  protocol was  developed within  IBM and
resulted in the creation of  VNET - IBM's internal use  network that
currently numbers 2297 nodes (as of Nov 26th 1986).  The reason  for
its successful growth within IBM was for one reason: its simplicity.
One could install RSCS in one hour on a VM system and be talking  to
another node within the same amount of time.

    RSCS provides two protocols for communication: file transfer and
interactive messages.  There  is no remote  login (this is  supplied
within  Vnet  by  a  parallel  network  known  as PASSTHRU), no mail
protocol, no  topology management  and very  little network control.
In addition,  when IBM  released RSCS  to the  public in 1972 (along
with  VM  Release  1),  it  only  allowed  for the connection of IBM
operating systems (VM, MVS, DOS) and no other operating system.   As
Bitnet  started  to  develop,  various  universities  developed  NJE
simulators for their own operating systems.  Urep (for Unix systems)
was developed at Penn State  University, jnet (for VMS systems)  was
also developed at Penn State  University, and the author later  sold
the  software  to  Joiner  Associates  for  a  healthy profit.  Some
vendors have taken it upon themselves to develop the NJE emulation -
as Prime has recently announced for their Primos operating system.

    Over half the nodes in Israel only have a limited access to  the
NJE protocol.  These nodes cannot send any interactive messages  and
some of them  cannot send any  files other than  RFC822 (Request For
Comments #822) mail.  Therefore, Israel currently has the  situation
where some  nodes have  greater "connectivity"  to the  network than
others.  That is one of the problems that needs to be resolved.  All
nodes in  the network  should be  able to  supply the  same level of
service to their users - no matter where that node happens to be  in
Israel.

    Even if the network topology was rearranged so that only a  very
few nodes with  limited software were  to be assigned  the status of
end-nodes,  we  would  still   have  the  problem  of   the  limited
functionality that RSCS provides.  Users have been asking for remote
login for a long time and this can currently only be provided to  VM
sites and at a high cost to network performance.

    In the  area of  performance, RSCS  loses out.   First of all it
uses a BSC protocol that requires an acknowledgement for every block
received over a link.  This requires line turnaround time and a loss
of throughput.  A full duplex protocol (HDLC) over our existing 9600
baud lines  would effectively  increase throughput  by approximately
30%-40%.   In  addition,  RSCS  does  not  do any sort of dynamic or
adaptive routing.  If  a link goes  down (which we  are already very
familiar with),  then data  communication to  that node  is shut off
completely.


II. WHY TCP/IP AND NOT SOMETHING ELSE?
    ==================================

    There  are  other  networking  protocols  that  exist and I will
review three of them: SNA, Decnet and ISO.

    II.A:  SNA:  It  is  interesting  to  note  that IBM's strategic
networking system  is not  used for  its own  internal network,  but
instead RSCS is  used.  IBM has  been trying to  convince the people
within its own network  that SNA will be  "good" for them, but  till
this date  nothing has  happened.  In  a lecture  by Tom Piatkowski,
currently  at  SUNY  Binghamtom,  but  more  importantly  one of the
original architects of SNA, he  noted that SNA was designed  for the
central management of a small  network and not for a  globe spanning
network.   SNA  excels  in  managing  a  campus  network;  a network
confined to a limited number of buildings and other small geographic
entities.

    A  recent  internal  memo  within  IBM  detailed the performance
tradeoff between using SNA and RSCS  over a 9600 baud line or  CTCA.
The file transfer times were almost identical for both protocols but
the SNA system took 40%-60%  more CPU time to execute  the transfer.
This  is  understandable  when  one  looks  at  the size of the RSCS
program compared to the size of the RSCS/SNA/VTAM program.

    SNA's other major problem is  also spelled with 3 letters:  IBM.
Other operating systems may  create gateways from their  networks to
IBM's, but only  a small number  have done so  to date and  the only
places that  have installed  these gateways  are those installations
that had to.  No installation to my knowledge has planned a  network
from the  start with  the assumption  of using  SNA gateways to four
non-IBM operating systems (three of which do not exist yet).

    Europe and for that matter  the rest of the world,  have decided
that IBM is not to be followed with their networking protocols.  For
that reason they have created the ISO, which I will get to shortly.

    II.B: DECNET: Much of what has been discussed in the section  on
SNA pertains also to DECNET.   VMS, Ultrix and TOPS-20 are  the only
operating  system  that  can  use  Decnet  and  three  months   ago,
Technology  Concepts  Inc.  announced  CommUnity,  which allows Unix
systems to participate in  a DECNET environment.  For  our purposes,
DECNET  only  supports  two  of  our  operating systems along with a
gateway to SNA - exactly the same numbers that SNA claims.

    II.C:  OSI:  The  International  Standards  Organization   (ISO)
created the Open Systems Interconnect (OSI) Reference Model  because
they saw that a uniform approach needed to be created for the entire
world.   In  five   years  time,  I   expect  we  will   see  4  OSI
implementations: VM, MVS, VMS and Unix.  I do not see that a NOS  or
Primos implementation will be available within that time frame but I
am always ready to be pleasantly surprised.  As of the end of  1986,
there  were  only  three  X.400  implementations available (the mail
protocol  of  OSI)  -  all  of  them  on an unofficial basis.  It is
important to remember that X.400 is not an OSI protocol but rather a
CCITT protocol that  the ISO is  considering to be  part of its  OSI
protocol suite.  No  FTAM (file transfer)  or Rlogin (remote  login)
implementations have been heard of.  Clearly, people are working  on
developing the  OSI protocols  but we  are currently  looking for  a
networking standard that will last us through 1992.

    It is interesting to note that OSI is not a protocol but  rather
a reference model that  provides for several families  of standards.
All that one  has to do  to become an  "OSI product" is  to document
what your  software does  in terms  of the  reference model.  DECNET
claims that DNA is an OSI product  as IBM claims that SNA is an  OSI
product.  Different vendors will  interpret the OSI reference  model
differently and in that case we will have many OSI products,  unable
to talk  to each  other.  That  is why  the NBS  (National Bureau of
Standards) in  the United  States has  created OSINET  - a  test bed
where vendors can try  out their software to  see if their OSI  will
talk to someone else's OSI.

    II.D: TCP/IP: So what is so great about Tcp/Ip?  For one, it  is
the oldest networking protocol around, predating DNA and SNA.  There
are 124 different  Tcp/Ip implementations that  run on 28  different
brands  of  hardware  (see  Appendix  3).   In addition there are 23
companies that make hardware  (boxes or cards) that  connect various
computers  to  a  Tcp/Ip  network.   If  we  ever  need to add other
operating  systems  to  our  network  (example:  MS/DOS), Tcp/Ip can
handle it.  Tcp/Ip works  in full duplex so  a leased line is  fully
utilized.  Arpanet and Csnet in the United States use it, as well as
numerous  individual  installations  in  Europe.   It provides three
standard  applications   protocols:  SMTP   (Simple  Mail   Transfer
Protocol), FTP (File Transfer  Protocol) and TELNET (Remote  Login).
All operating  systems in  Israel have  Tcp/Ip implementations  (NOS
Tcp/Ip to be available from CDC - April 1987).

    Tcp/Ip  can  run  on  leased  lines  (9600 baud up to T1 speed),
Ethernet, X.25 circuits, Pronet, etc.   It is more in the  spirit of
the OSI reference model than SNA or DECNET since the physical and at
least part of the link layer can be swapped out and substituted  for
with no change in the transport or session layers.

    Some Israeli universities have  already made a heavy  commitment
to  Tcp/Ip.   Hebrew  University,  Ben  Gurion  University, Weizmann
Institute of Science and Tel Aviv University have most of their  own
computers interconnected via Tcp/Ip.  By installing a Tcp/Ip network
we  will  be  gaining  access  to  the  many  Sun workstations, Lisp
machines  and  other  unique  hardware  that  exists at each campus.
Currently,  these  machines  are  available  locally  at  individual
campuses  via   local  Tcp/Ip   networks.   Since   Machba  (Israeli
InterUniversity Organization) has  been considering the  purchase or
sharing of  a Cray,  it should  be noted  that Cray  has developed a
Tcp/Ip implementation for their Unicos operating system.

    Most importantly,  the DOD  (Department of  Defense) has  stated
that it intends to convert to ISO standards when such standards  are
made available.  To this  end, the Northrop Research  and Technology
Center has recently introduced RFC983 - which defines a strategy for
conversion in an evolutionary  manner as opposed to  a revolutionary
manner.  They  offer a  free ISO  Development Environment  that they
have developed (written in C)  that currently runs on Unix,  VMS and
PC/DOS.

    It is clear that the conversion route from Tcp/Ip to ISO  (since
they are so similar and parts of ISO are drawn directly from Tcp/Ip)
will be the smoothest.  The  alternatives before us are few:  either
to sit still and continue to use the RSCS protocol for many years to
come or to convert now to Tcp/Ip, under the assumption that it  will
be  replaced  by  the  ISO  suite  of  protocols  when  they  become
available.  It is my personal  feeling that the upper layers  of the
ISO  protocol  (levels  5-7)  are  at  least  5-8  years  away  from
implementation.

    II.E: Caveats: There is also a negative side to Tcp/Ip.  Certain
implementations are buggy and will require a large amount of systems
programming   intervention.    We   will   try   to   avoid    those
implementations but it should be known from the start that Tcp/Ip is
not bug free (neither is  any other networking or operating  system)
and  we  may  run  into   a  glitch  along  the  way   with  certain
implementations.

    The implementations that  do work properly  may be lacking  some
feature  that  we  will  realize  later  on  that  we  need.   It is
impossible to know at this stage  of the game what all the  features
that are in  Tcp/Ip (i.e. dynamic  routing, adaptive routing,  ICMP,
UDP) that will be needed.

    Tcp/Ip lacks certain features that we may need to develop in the
future (but do not exist today).  These include: accounting -  there
is no  facility to  gather statistics  on path  usage, data transfer
rates, etc.; authentication and access control - suppose we wish  to
limit data  transfer limits  for students  - currently  there is  no
mechanism  to  accomplish  this  with  Tcp/Ip.  The Arpanet realizes
these requirements and  has informed vendors  to be prepared  in the
future to include access-control and accounting machanisms in  their
gateways.

    Most of the assumptions for a smooth conversion depend that  the
Tcp/Ip network and RSCS network work in parallel for a period of two
years.  This involves an added cost that needs to be considered.

    Lastly, a network of this nature needs staffing.  It doesn't run
by itself  and it  doesn't fix  itself.  In  general, you  need more
staff  to  run  a  network  than  not  to  run  a network.  Of the 6
operating systems in Israel, four have sufficient systems  expertise
scattered through  the various  universities.  The  two systems that
lack "networking & system hackers" are Primos and VMS.  All computer
centers should be prepared to have one full-time person whose  major
responsibility is the running of their LAN.


III. WHAT WILL IT COST?
     ==================

... this section removed for EARN and Bitnet distribution ...


IV. TIMETABLE FOR CONVERSION
    ========================


IV.A: Stage I:

    This stage involves  the interconnection of  2 or more  separate
Tcp/Ip  LANs.   Currently,  there  are  Tcp/Ip  networks  at  Hebrew
University (CS Department only), Tel Aviv University (CS  Department
only),  Bar  Ilan  University  (CS  Department  only)  and  Weizmann
Institute of Science (CS Department and Computer Center).  There are
two alternatives to accomplish this:

    A) VM to VM:  The Wiscnet package comes  with a BSC driver  that
can run a point to point leased line.  All 4 Universities  mentioned
above have VM systems but currently only one of them runs Wiscnet.

    B) Tcp/Ip  boxes (Bridge  GS/3M): This  would allow  any of  the
current LANs mentioned above to interconnect.

... two paragraphs removed for EARN and Bitnet distribution ...

    Synopsis:  identify  potential   and  willing  sites   with  the
necessary  software,  then  order  necessary  hardware.   This stage
should be completed no later than September 1987.


IV.B: Stage II:

    This stage is just an extension of Stage I. All 43 Israeli  EARN
sites should be running Tcp/Ip on their system and a parallel Tcp/Ip
network should exist alongside the current RSCS network.  This stage
will be the one to work out all the bugs between the various systems
(inter-machine translation  problems, performance  and optimization,
etc.)

    While this work is going on, the sites from Stage I should start
experimenting with  using their  local Tcp/Ip  services to  send and
receive data from the  RSCS EARN network.  Makeshift  solutions will
be made and the specific problems and necessary global solutions for
Israel will be identified in this stage.

    This stage depends on the  fact that alternate lines will  exist
for each of the  43 computers currently connected.   These alternate
lines can  be either  9.6Kb or  64Kb Sifranet  lines.  The important
point in this matter is that alternate lines have to exist for  this
to work.

    Synopsis:  Order  equipment  for  all  43 Israeli nodes, install
software and hardware.  This stage should be completed no later than
June 1988.

IV.C: Stage III:

    This is the final stage.   It involves the disconnection of  the
9600 baud  leased lines  and the  end to  the RSCS  network that  is
currently  in  place  in  Israel.   But  before  this can be done, a
gateway needs to exist at Tel Aviv University (our EARN gateway  for
the country) that  will send and  receive Tcp/Ip datagrams  from one
side and send and receive  RSCS files and interactive messages  from
the other.  It will be up  to each site to decide whether  they wish
to use the new Tcp/Ip functions (i.e.  SMTP or FTP) or whether  they
wish to take their old  RSCS user interfaces and make  the necessary
modifications (on a  local basis) so  that they can  communicate via
the  Tcp/Ip  network.   It   will  not  be  Tel   Aviv  University's
responsibility to modify every user  program on all 43 systems  that
currently communicate with EARN.

    It  will  be  Tel  Aviv  University's responsibility to design a
gateway with the following capabilities:

    FTP: If a file arrives  via EARN, destined for an  Israeli user,
then an FTP transaction should be created for delivering the file to
the user.  In certain  cases, FTP to a  system may not be  possible.
In that case, TAU must provide the necessary modifications for  that
system so that they can receive FTP transactions.  An example  would
be  a  file  destined  to  a  VM  site.   Since FTP requires a write
password  to  the  person's  disk  -  a  vanilla FTP would not work.
Possible alternatives might be: a)  sending the file to an  FTP sink
user at the intended  node, along with a  mail file to the  intended
user informing him that a file has arrived and can be received  from
his local FTP sink user; b) modifications to Wiscnet FTP that  would
allow FTP to the user's VM spool (preferred solution).

    The  reverse  also  needs  to  be  handled.  If a user in Israel
wishes  to  send  a  file  to  a  user in Germany via EARN, then the
gateway  at  TAU  must  accept  the  FTP request and receive all the
intended packets on behalf of the user in EARN.  It will then  issue
a sendfile on the user's behalf, counterfeiting the original  user's
id and  nodename instead  of its  own.  There  are many details that
need to be worked out for this gateway (such as what format to  send
data in: netdata, disk dump, punch, print, specifying RSCS dependent
options on the FTP request - like priority, class, forms, etc.)

    SMTP: Israel will register itself as being a domain of AC.IL and
that  all  mail  destined  for   this  domain  should  be  sent   to
MAILER@TAUNIVM.  This  mailer will  then deliver  the mail  via SMTP
methods rather than  RSCS methods.  The  reverse must also  be taken
care of.   This area  is considered  to be  the easiest  since other
installations throughout the world have already tackled this problem
and have come up with software solutions that we can use.  It should
be noted that Arpanet has already assigned an upper level domain  to
Israel (.IL) and that there  is already a node at  Hebrew University
listed  as  a  host  in  Arpanet  (HUJI.AC.IL).   It would then be a
trivial matter to  define all other  hosts in Israel  in the Arpanet
hosts  table,  thereby  giving  us  equal  access to Bitnet (via the
planned  gateway  at  TAU),  and  via  the X.25 link to Arpanet from
Hebrew University.

    TELNET: This  will not  be supported  in the  direction of  EARN
since it  is not  supported today.   Users will  only be  allowed to
TELNET within Israel.

    RSCS Interactive messages: This is  one area that we may  not be
able to implement.   The ISO protocols  do not support  this kind of
facility and neither does the Tcp/Ip protocol.  We will only be able
to determine  whether we  can implement  this near  the end of stage
III.  A  while back,  Arpanet implemented  a SEND  protocol that was
fairly similar  to RSCS  interactive messages.   It required  a SEND
server at the  origin and destination  sites.  This service  did not
catch on with  Arpanet users since  they found it  a bother to  know
whether a  user was  logged on  at the  time.  Several people within
Arpanet  have  indicated  that  the  SEND  protocol  is very easy to
implement since  it never  waits for  an acknowledgement  but rather
just sends a datagram and exits.  We may be able to use some of  the
early Arpanet work but it will have to remain as a low priority work
item during the general timetable.

    It should be noted that  some of this development work  could be
done in the  framework of a  graduate student project.   Ariel Frank
(Bar Ilan University)  has indicated that  he has graduate  students
that he could assign with subsets of the above stated work.  Various
other universities  may also  have graduate  students that  could be
utilized to  develop certain  components that  have been  delineated
above.

    Synopsis: A lot of software development should have already been
started by the  end of Stage  I. This stage  should be completed  no
later than January 1989.


IV.D: Stage IV:

    This stage involves the conversion to ISO.  As solutions  become
available on Arpanet (i.e.  RFC983;  see Appendix 6), we will  adopt
them.  I foresee this stage lasting over a period of 2-3 years after
January 1989.  It is quite possible, that development projects  will
be assigned to Israel (i.e. from  IBM, CDC, DEC, etc.) in this  area
over the next five years.


V. APPENDIX 1: List of nodes in Israel
   ===================================


... this section removed for EARN and Bitnet distribution ...


APPENDIX 2: Connecting PC's to the Tcp/Ip network
=================================================

... this section removed for EARN and Bitnet distribution ...


APPENDIX 3: List of Tcp/Ip Hardware and Software Vendors
========================================================

... this section removed for EARN and Bitnet distribution ...


APPENDIX 4: The Tcp/Ip Reference Model
======================================

Applications Layer    (7)
Presentation Layer    (6)
Session Layer         (5)
Transport Layer       (4)
Network Layer         (3)
Data Link Layer       (2)
Physical Layer        (1)


APPENDIX 5: Glossary of acronyms
================================

Application Level:

FTP    - File Transfer Protocol - transfer of files and directories
         between computers
TELNET - Virtual Terminal Protocol - interactive remote logon
SMTP   - Simple Mail Transfer Protocol - RFC822 mail
BSMTP  - Batch Simple Mail Transfer Protocol
NFS    - Network File System - SUN protocol for accessing remote
         files

Transport Level:

TCP  - Transmission Control Protocol - sliding window protocol,
       connection oriented, flow control, multiplexing

Network Level:

IP   - Internet Protocol - packet addressing and fragmentation
UDP  - User Datagram Protocol - connectionless service for host to
       host comunications
ICMP - Internet Control Message Protocol - reports on transmission
       errors, flow control, first-hop gateway redirection and
       routing information
ARP  - Address Resolution Protocol - converts 32-bit Internet
       addresses to 48-bit Ethernet addresses.
EGP -  Exterior Gateway Protocol - used to exchange information
       between gateways

Data Link Level:

DLP  - Data Link Protocol (also known as DLAP - Data Link Access
       Protocol) - provides connectionless service for sending and
       receiving datagrams


APPENDIX 6: References
======================

1) RFC942 - Transport Protocols for the Department of Defense Data
   Networks; Feb 1985

2) RFC983 - ISO Transport Services on Top of the TCP; Northrop
   Research; April 1986

3) RFC985 - Requirements for Internet Gateways; NSF; May 1986

4) Tcp/Ip Vendor's Guide; SRI; Feb 1987

5) DDN Protocol Handbook; SRI; Dec 1985

6) Ethernet: Distributed Packet Switching for Local Computer
   Networks; Metcalfe and Boggs; ACM Communications, July 1976

7) Introduction to Local Area Networks; DEC; 1982, EB-22714-18

8) Proceedings of Campus Network Plans and Pc/Ip Workshop;
   University of Maryland; Dec 1985

9) Computer Networks for Scientists; Jennings, Landweber, Fuchs,
   Farber, Adrion; Science; Feb 28, 1986

10) Notable Computer Networks; Quarterman and Hoskins; ACM
    Communications, Oct 1986


APPENDIX 7: EARN Migration Plans
================================

EUROPEAN ACADEMIC RESEARCH NETWORK


The migration of EARN to use ISO protocols,
summary of the proposed strategy and tactics.
Subject to ratification by the EARN Board of Directors and further study

                                                       issued by
                                                       P Bryant
                                                       20 April 1987

_______________________________________________________________________


1 Summary

EARN is determined to migrate to use ISO protocols as soon as possible.

It is vital that during this migration there is no significant loss of
service to the users.

Until recently there have not been the products available to start a
migration. There are now a number of developments which suggest that the
first stages of a migration could now be undertaken. The completion of
the process will take several years.

The EARN Board of Directors set up a working party to define the
migration path which is just concluding its work. This paper is  a
summary of their report. The full report is now under discussion.


2 Why migrate?

There are three reasons for EARN wishing to use ISO protocols:

- EARN had to obtain permission from the various national regulatory
authorities in order to operate. This was because it infringed the PTT
monopolies in some countries. CEPT, the European advisory body for such
matters, agreed to recommend EARN should be permitted as long as they
migrated to ISO protocols by the end of 1987.

- EARN uses the fairly primitive IBM NJE protocols which provide a store
and forward network for file transfer and mail. The use of ISO protocols
would provide a broader range of services. ISO protocols are expected to
be available under most systems whereas NJE is restricted to the more
popular ones.

- All the west European countries (and many others) are expected to base
their academic networking on ISO protocols. EARN must cooperate and
interwork with these networks.


3 The state of protocols

The CCITT X.25 protocol is widely available but only in its 1980
version. The 1984 version is required for the support of ISO protocols.
The PTT's planed dates for the 1984 version are not yet clear. Various
private switch suppliers now provide it.

The X.400 mail protocol is available in a number of experimental or
pilot versions. The use of this protocol is likely to expand rapidly as
the PTTs provide services based on it in the near future.

FTAM (the ISO file transfer protocol) is only now becoming stable and
implementations are not expected for some time.

VTP (virtual terminal protocol) and JTP (job transfer protocol) are both
unstable and implementations are not expected for a long time.


4 The parts of EARN

EARN can be regarded as two parts - the national parts and the
international ones.

The migration of EARN within a country must be undertaken in close
cooperation with other national activities and will therefore not be
directed centrally.

The migration of the international parts will be directed by the EARN
Board. All the international EARN nodes are IBM ones. This is the
principle subject of this paper.

It is essential that the international and national migrations are
carefully coordinated.


5 The first stage, strategy

The only ISO protocol that can currently be adopted is X.25.

The strategy is to operate the IBM NJE protocol over X.25. This can be
achieved using IBM products. The users will not need to be aware of the
change since the strategy will not alter the services provides or the
interface to the user.

The use of NJE over X.25 demands the use of X.25 permanent virtual
circuits. These cannot be provided internationally by the PTTs and
therefore EARN will have to provide an interim  private X.25 network.
This has the secondary advantage that X.25 (1984) can be used which is
not currently available from the PTTs and this needed to support the
higher level ISO protocols.


6 The first stage, tactics

A survey has shown that private switches which provide permanent virtual
circuits and X.25 1984 are available.

The number of switches and their location depend on the cost of switches
and the cost of lines. An incomplete study suggests that initially there
should be two switches- one serving the north of Europe and one the
south. There will need to be some relocation of lines but this is
expected to be done over a fairly long period of a year.

It is intended to use the X.121 address scheme. This defines the first
four digits of an address. Eight digits will remain for use within a
country which will be allocated according to national needs although it
is suggested that four digits define a site and four for use within a
site. A two digit subaddress will not be policed by the network.

Initially only a few sites with good networking expertise will be
connected. The rest of the international sites will be migrated at a
later date and in some cases when lines are relocated.

A few sites will need additional software which may also cause a slight
delay.

The EARN services will be enhanced by the addition of the X.3, X.28, and
X.29 services on some sites. This will not be very useful until the
national parts of EARN have migrated to X.25 or gateways are provided to
other X.25 networks.

The tactics within a country will be the responsibility of the country.
Some countries will want to migrate in step with the international parts
of EARN. Others will want to wait. Others may want to provide gateways
and relays to existing or proposed national networks.

The use of Coloured Book protocols and DECNET will be allowed for an
interim period to meet the needs of some specific groups of users. This
will allow good connectivity between Ireland, the UK, and some other
sites who use Coloured Books. DECNET is popular with the astronomy,
space physics and high energy physics communities.


7 The second stage, strategy

The first higher level ISO protocol to be promoted will be X.400 mail
protocol.

Some countries are expected to migrate with the international part of
EARN. They will be installing switches for this purpose. These switches
may be used to enhance the international parts of EARN and require some
change to the EARN topology.


8 The second stage, tactics

There are a number of X.400 systems now available.

In particular the IBM Heidelberg system will operate on IBM VM systems
and so it will be mounted on many of the international nodes. This
system has the property that parts of the system can be located remotely
over the NJE network thus allowing greater penetration of EARN by X.400
than the extent of the X.25 network would suggest.

Other X.400 systems, such as EAN, are expected to interwork with the
Heidelberg one and recent tests are encouraging. These will be of
greatest interest within a country.

Some countries are expected to be part of the EARN address space as they
migrate. Other will have different schemes and gateways and relays will
be provided to maintain a service. Various promising products are in
existence or being produced.

The most important relay will be between X.400 and RSCS mail systems. A
suitable product is being produced in Germany.


9 The fourth stage, strategy

The use of NJE, DECNET, and Coloured Book protocols will be phased out
leaving a pure ISO network. At this stage it will be possible to use the
public networks.

The removal of these protocols depends on the provision of FTAM (the ISO
file transfer protocols) which should be available in a year or two.


10 The fourth stage, tactics

Currently there are no suitable versions of FTAM available and no firm
indication of dates. EARN will wait for suitable products and promote
them as soon as possible.

The fourth stage will require further study. It is unlikely to be
concluded before 1989.


11 Time scales

The international switches plus a few connections could be provided by
the end of 1987. The complete migration of the international part of
EARN to X.25 will take to the middle or end of 1988. NJE services must
be provided immediately.

X.400 can be provided on some nodes by early in 1988 with all
international nodes operating it at the end of 1988.

The use of Coloured Book and DECNET protocols will only be provided
where needed. Planning will be on a bilateral basis.

The migration of countries has not yet been studied in detail. There
will be gateways and relays to some existing X.25 national networks at
the end of 1987. a small number of national networks within the EARN
address scheme are expected towards the end of 1988.

Implementations of FTAM are expected in 1988 or 1989.

NJE will be phased out as soon as FTAM is proved to be able to offer a
comparable service. Manufacturers plans and timescales are not
available.


12 Standards

EARN will follow the emerging functional standards being elaborated by
CEN/CENELEC. EARN is also following the activities of RARE. This is
important to ensure that EARN can interwork with other academic networks
which are all expected to follow the same standards and functional
standards.

It must be noted that EARN is a service provider and does not intend to
take part in standards activities as a primary activity. In addition,
EARN does not intend to develop products but to use those provided by
others.


13 Conclusions

EARN is moving towards the use of ISO protocols as fast as possible. The
main delay is caused by the lack of implementations of protocols which
is not surprising considering the unstable nature of some of them.

EARN is dedicated and will remain dedicated to providing the best
possible service to the European academic and research community.


APPENDIX 8: Israel viewpoint on EARN Migration Plans
====================================================


Date: July 1, 1987

    This section will address some of the points raised in the  EARN
Transition paper (April 20, 1987) by Paul Bryant (Appendix #7).   In
order to follow the points made, it is advised to have a copy of the
EARN Transition paper available.

    1) Israel is determined to migrate to the ISO protocols.

    2)  Israel  agrees  entirely  with  the  need to abandon the NJE
protocols and adopt the OSI international standards.

    3)  The  1984  X.400  standard  finally  has  a few experimental
implementations available.  IBM's announcement of X.400 support  for
MVS systems fails to mention that availability is 3Q88.  As yet, IBM
has not announced  X.400 support for  VM.  We also  realize that ISO
has not adopted the CCITT X.400 standard and that the newly  revised
1988 X.400 standard  will be (on  certain levels) incompatible  with
the 1984 version (i.e. mailing and distribution lists).  If we  take
X.400 as an example,  we can assume that  it takes 4 years  from the
time a standard  is finalized until  the first half  dozen supported
implementations appear in the marketplace.  OSI's timetable in  1985
stated that  CASE, FTAM,  JTM, MOTIS  and VTP  (the top  application
level)  were  all  to  become  IS (International Standards) by 1987.
Unfortunately, all of  them are still  DP or DIS  and some (JTM  for
example) are therefore approximately 4 years behind schedule.

    ISO has also published a timetable for the Management  Framework
which includes standards for fault management, accounting, security,
configuration, etc.  Their initial timetable states IS completion by
4Q90.  If we  assume that ISO  will meet this  deadline then we  can
only hope to see the  first half dozen supported implementations  of
the *complete* OSI model by 1994  (if we are to use the  X.400 model
as an example).

    It is the period of the next 7 years that the national  academic
network of Israel will follow an alternate path to the ultimate  OSI
solution.

    4) Israel will be  a full partner in  all EARN decisions on  the
international segment of the  network.  It is Israel's  intention to
implement all EARN recommendations for its international link.

    5) Israel will participate  in the interim private  X.25 network
that EARN wishes to construct between the various country gateways.

    6) It is stated in this section that each country is responsible
for what occurs within its own country.  "Others may want to provide
gateways and  relays to  existing and  proposed national  networks."
Ireland and England are mentioned as two examples.  Israel will fall
into this category.

    7) Agreed.

    8) As X.400  products become available  we will implement  them.
As EARN proceeds with X.400, so too shall Israel on an international
level.

    9) Agreed.  DECNET  and Coloured Book  protocols will be  phased
out as  ISO protocols  become available.   We are  just not quite as
optimistic ("should be available in a  year or two") as EARN is  and
therefore see the conversion to  Tcp/Ip as a strategy for  supplying
all the services that ISO is planning, on an interim basis.  If  for
some reason  the ISO  deadlines slip,  we will  continue to function
with our national Tcp/Ip  network until the necessary  protocols are
available.

    10) It is stated in the Transition paper that the conversion  is
"unlikely to be concluded before 1989."  The OSI FTAM standards (all
4 parts: 8571/1,  8571/2, 8571/3, and  8571/4) are still  DIS (Draft
International Standard), the same status they have been since  1986.
If they do turn to IS before the year is over, I do not foresee more
than 5-6  supported implementation  available before  1990.  A  more
realistic timeframe would be 1992.

    11) Israel  views these  timescales to  be extremely optimistic.
When  dealing  with  existing  services  (file transfer, interactive
messages and mail) currently provided by EARN, it is very  important
to have contigency plans in case of unforeseen delays.  We view  the
conversion  to  Tcp/Ip  as  an  insurance  policy that starts paying
dividends today.

    12) Agreed.

    13) "EARN is moving towards the use of ISO protocols as fast  as
possible, the main delay is caused by the lack of implementations of
protocols which is not suprising considering the unstable nature  of
some of them".  That is  EARN's conclusion.  Israel is committed  to
ISO conversion as the standards become available.  We see Tcp/Ip  as
an interim solution over the next 7 years.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Jul-87 10:40:32 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Ethernet meltdowns

During the last week or so we have run into several oddities on our
Ethernets that I thought might interest this group.  Nothing that will
surprise any veterans, but sometimes war stories are useful to people
trying to figure out what is going on with their own net.

For several months, we have been having mysterious software problems
on one Ethernet.  THis is our "miscelleanous" network.  No diskless
Suns.  Several Unix timesharing systems, a few VMS machines, a DEC-20,
and some Xerox Interlisp-D machines.  The problems:
  - every week or so, all of our Bridge terminal servers crashed.
	When it happened, they all crashed at the same time.
  - fairly rarely, a Celerity Unix system would run out of mbufs.
  - a Kinetics Ethernet/Appletalk gateway running the kip 
	code would hang or crash (not sure which) every few days

We sent a dump of the Bridge crash to Bridge.  Celerity wouldn't talk
to us because we made a few changes to the kernel.  Kinetics swapped
hardware for us, so we knew it wasn't hardware, but we still haven't
figured out how to debug the problem.  (The author of the software
suspects the Ethernet device driver, but it's going to take us months
to learn enough about the infamous Intel Ethernet chip to find a
subtle device-level problem.  Typical known problem: packet sizes that
are a multiple of 18 bytes hang the hardware when the phase of the
moon is wrong.  How's a bunch of poor Unix hackers gonna debug a
system where the critical chip has a 1/4 inch thick bug list, which we
don't have a copy of.)  Anyway, Bridge finally came back with a
response that unfortunately I have only second-hand "We got a very
high rate of packets from two different Ethernet addresses each
claiming to be the same Internet address.  This shouldn't cause us
problems, but does.  We found the problem, and it will be fixed in the
next release."  They gave us the two Ethernet addresses and the
Internet address.  Two Celerities were claiming to be some other
machine.  So we break out our trusty copy of etherfind.  (This is a
Sun utility that lets you look at packets.  There's a fairly general
way of specifying which ones you want to see, and they will decode the
source, destination, and protocol types for IP.  We've got lots of
Ethernet debugging tools, but this is by far the most useful for this
kind of problem.)  It turns out that the Celerities have the infamous
bug that causes them to get the addresses wrong in ICMP error
messages.  Before proceeding with the war story, let me list the 
classic 4.2 bugs that lead to network problems:

1) Somebody sends to a broadcast address that you don't understand.
There are 6 possible broadcast addresses.  For a subnetted network
128.6.4, they are 255.255.255.255, 128.6.4.255, (the correct ones by
current standards) 128.6.255.255 (for machines that don't know about
subnetting), and the corresponding ones for machines that use the old
standards: 0.0.0.0, 128.6.4.0, and 128.6.0.0.  We have enough of a
combination of software versions that there is no one broadcast
address that all of our machines understand.  So suppose somebody
sends to 128.6.4.255.  Our 4.2 machines, which expect 0.0.0.0 or
128.6.0.0, see this as an attempt to connect to host 255 on the local
subnet.  Since IP forwarding is on by default, they helpfully decide
to forward it.  Thus they issue ARP requests for the address
128.6.4.255.  Presumably nobody responds.  So the net effect is that
each broadcast results in every 4.2 machine on the Ethernet issing an
ARP request, all at the same time.  This causes massive collisions,
and also every machine has to look at all those the ARP requests and
throw it away.  This will tend to cause a momentary pause in normal
processing.

2) Same scenario, but somebody has turned off ipforwarding on all the
4.2 machines.  Alas, this simply causes all the 4.2 machines to issue
ICMP unreachable messages back to the original sender.  This still
results in massive collisions, but at least this time only one machine
(the one that sent the broadcast) has to process the fallout.  That's
if everything works.  Unfortunately, some 4.2 versions have an error
in setting up the headers for the error message.  They forget to
reverse the source and destination, as I recall.

3) Somebody sends a broadcast UDP packet, e.g. routed routing
information.  Hosts that are not running routed (or whatever) attempt
to send back ICMP port unreachable.  They are supposed to avoid
doing this for broadcasts, but the test for broadcastedness in udp_usrreq 
doesn't agree with the one in ip_input, so for certain broadcast
addresses, every machine on the network that isn't running the
appropriate daemon will send back an ICMP error.  Again, lots of
collisions.  If you have a few gateawys running routed, but most
hosts not running it, you'll have network interference every 30
sec.  Then again, there are those machines where the ICMP messages
have the wrong source and destination address.

Now back to the war story.  The case I actually saw with etherfind was
caused by routed broadcasts.  Our 2 Celerities would each respond with
ICMP port unreachable.  Unfortunately, they have the bug that caused
the IP addresses in the ICMP error message to be wrong.  I think it
ended up sending packets with source address == the machine that had
sent the routed's, and destination == the broadcast address.  This
would explain why our Bridge terminal servers were seeing packets from
two different Ethernet addresses, both claiming to be a different
machine.  We had certainly been seeing spotty network response, and as
far as I can see, it went away when we fixed these problems.  As far
as we know, the Bridge terminal servers and Kinetics gateways have
both stopped crashing, and the Celerities have stopped losing mbuf's.
What we suspect is that some obscure case came up that create a
problem more serious than the one we saw with etherfind.  Note that
one of the failure modes is that certain broadcasts can lead to error
messages sent to the broadcast address.  We haven't analysed the code
carefully enough to be sure exactly what conditions trigger it, but we
suspect that the two machines may have gotten into an infinite loop of
error messages.  Since the messages would be broadcasts, everyone on
the network would see them.  This is generally called a "broadcast
storm".  The best guess is that both the Bridge and Kinetics crashes
were caused by subtle bugs in their low-level code that fail under
very heavy broadcast loads.  Probably the Celerity "mbuf leak" is
something similar.  Unfortunately, without a record of the packets on
the network at the exact time of failure, it is impossible to be sure
what was going on.  But Bridge's crash analysis seems to indicate a
broadcast storm involving the Celerities.

The fix to this is to make sure every one of your 4.2 systems has
been made safe in the following fashion:

 - turn off ipforwarding, in ip_input

 - in the routine ip_forward (in ip_input), very near the beginning
	of the routine, there is a test with lots of conditions,
	that ends up throwing away the packet and exiting.  Add
	"! ipforwarding || " to the beginning of the test.

 - in udp_usrreq, a few pages into the routine, in_pcblookup is
	called to see whether there is a port for the UDP packet.
	If not (it returns NULL), normally icmp_error is called
	to send port unreachable.  However there is a test to
	see whether the packet was send as a broadcast.  If so,
	it is simply discarded.  That test must agree with the
	test for broadcastedness in ip_input.  This seems to
	differ in various implementations, so I can't tell you
	the code to use.  One common bug is to forget that
	ip_input recognizes 255.255.255.255 as a broadcast
	address.  It normally does this in a completely different
	place than it tests for other broadcast addresses.
	So you may be able to add something like
	"ui->ui_dst.s_addr == -1 || " to the test in udp_usrreq.

These apply to 4.2.  4.3 probably doesn't need them all, and may not
need any of them.

Now for the second war story.  Our computer center recently bought a
few diskless Suns for staff use.  Until then, all diskless Suns had
been on separate Ethernets separated from our other Ethernets by
carefully-designed IP gateways.  However the computer center figured
that a small number of these things wasn't going to kill their
network, so they connected them to their main Ethernet.  On it is a
VAXcluster (2 8650's), a few 780's, some terminal servers and other
random stuff, and level 2 bridges (Applitek broadband Ethernet bridges
and Ungerman-Bass remote bridges) to more or less everywhere else on
campus.  Since they were still setting up the configuration, it isn't
surprising that a diskless Sun 3/50 got turned on before its server
was properly configured to respond.  Nobody thought anything of this.
We first discovered there were problems when we got a call from
somebody in a building half a mile away that his VAX was suddenly not
doing any useful work.  Then we got a call from our branch in Newark
saying the same thing about their VAXes.  Then someone noticed that
the cluster was suddenly very slow.  Well, it turns out that the Suns
were sitting there sending out requests for their server to boot them.
These were broadcast TFTP requests.  Unfortunately, they used a new
broadcast address, which the Wollongong VMS code doesn't understand.
So VMS attempted to forward them.  This means that it issued an ARP request
for the broadcast address.  There is some problem in the Wollongong
TCP that we don't quite understand yet.  It seems that whenever there
are lots of requests to talk to a host that doesn't respond to ARP's,
the whole CPU ends up being used up in issuing ARP's.  For example,
when something goes wrong with our IBM-compatible mainframe (which is
used to handle most of the printer output for the cluster, using Unix
lpd implementations on both systems) the VAX cluster becomes unusable.
As far as we can tell, it is spending all of its time trying to ARP
the mainframe.  In this case, the same phenomenon was triggered
by the attempt to forward broadcast packets.  Since our VMS systems
mostly sit on networks that are connected by level 2 bridges instead
of real IP gateways, broadcasts go throughout the whole campus, and
essentially every VMS system is brought to its knees.  Unfortunately,
there is no way we can fix this.  The Sun broadcast is being issued
by its boot ROM, which is the one piece of software we aren't equipped
to change, and we don't have source to the Wollongong code.  So the
solution for the moment is to put the Suns on a subnet that is
safely isolated behind an IP gateway.  This fixes the problem, because
IP gateways don't pass broadcasts, or they only pass very carefully
selected ones.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Jul-87 11:45:00 EDT
From:      holtj%zeus.DECnet@AFSC-SD.ARPA ("ZEUS::HOLTJ")
To:        comp.protocols.tcp-ip
Subject:   The fixing of problems with Wollongong WIN/TCP 3.0


                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      8-Jul-1987 07:41 PST
                                        From:      Jack C. Holt, SSgt 
                                                   HOLTJ 
                                        Dept:      2080CS/DOAS
                                        Tel No:    643-2254

TO:  _MAILER!                             ( _DDN[MRC%PANDA.COM@SUMEX-AIM.STANFORD.EDU] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )

CC:  TSgt Thomas                          ( THOMASJR )
CC:  Communications Administration        ( COMADM )
CC:  DANAHY, DANIEL J.                    ( DANAHY )

Subject: The fixing of problems with Wollongong WIN/TCP 3.0

    In following up the message which I sent yesterday in reply to 
Mark Crispin's message about the Wollongong to DEC20 interface:  I 
contacted Jerry Scott of Wollongong yesterday about our problems 
talking to DEC20's as well as other problems.  It appears that our 
problems with talking to SRI-NIC.arpa (a DEC20) were caused by an 
incorrect installation (gateways were properly set up).  

    After working with Mr. Scott things seem to have cleared up and 
we have been able to send several messages to SRI-NIC.arpa with no 
problems.
    
    Also, Mr. Scott showed a great deal of concern about solving 
our problems with mailer.

------

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Jul-87 12:19:00 EDT
From:      WGRCU@CUNYVM.BITNET (Bill Rubin)
To:        comp.protocols.tcp-ip
Subject:   New Mailing List on IBM TCP/IP for VM product

A new mailing list has been established at CUNYVM. Information is as
follows.

*
*  IBMTCP-L IBM TCP/IP For VM List
*
*   IBMTCP-L is intended for discussion of the IBM TCP/IP For VM
* program offering (5798-FAL). It is also for discussion of the
* IBM DACU (7170), 8232, 9370 Ethernet adapter and other similar
* hardware, as they relate to the IBM product.
*

To sign up, send the following message to LISTSERV at CUNYVM:

SUBSCRIBE IBMTCP-L Your name

Bill Rubin

(Sorry for the duplicate mailings)

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jul 1987 12:19 EDT
From:      Bill Rubin <WGRCU%CUNYVM.BITNET@wiscvm.wisc.edu>
To:        <ibm-nets@bitnic>, <future-l@bintic>, <liaison@bitnic>, <tcp-ip@sri-nic.arpa>
Subject:   New Mailing List on IBM TCP/IP for VM product
A new mailing list has been established at CUNYVM. Information is as
follows.

*
*  IBMTCP-L IBM TCP/IP For VM List
*
*   IBMTCP-L is intended for discussion of the IBM TCP/IP For VM
* program offering (5798-FAL). It is also for discussion of the
* IBM DACU (7170), 8232, 9370 Ethernet adapter and other similar
* hardware, as they relate to the IBM product.
*

To sign up, send the following message to LISTSERV at CUNYVM:

SUBSCRIBE IBMTCP-L Your name

Bill Rubin

(Sorry for the duplicate mailings)
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Jul-87 13:02:57 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Wollongong TCP/IP for VAX/VMS

Would you like to propose an alternative.  The other major
commercial offering (DTC/COMPION/GOULD/Whatever) ACCESS for
VMS is WORSE.  In addition the morons at the current company
(Internet Solutions or Network Solutions, I can't remember)
had little understanding of the internet at all.  Their primary
VMS worker kept insisting that when they got a name server
implementation working it would fix their broken routing
problems.  I posted a rather lengthy description of the problem
after that to the net and got some more calls from the management
of the company but the code never got fixed.

Woolengong, in addition to being blastedly expensive, falls short
of being useful.  In addition to having no name server support and
no mail system to speak of, their low level Ethernet kills the entire
system trying to ARP.  This happens when it receives broadcast datagrams
that it is trying to forward, or even if a host it has traffic for is
down.  It spurts a continuous stream of ARP's that never  get answered
which seem to be done at some priority that causes the VAX's to become
virtually unresponive.  Their inability to deal with any sort of broadcast
means we have to segregate them from nets with real hosts on them.
I frequently have to proxy arp for downed hosts when it is busy arping
for them and they aren't capable of answering.

Someday, someone will make a commercial VMS TCP offering that works
worth a damn, and when they do RUTGERS will immediately put it on
every single VMS machine we have (and we have a lot).

-Ron

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Jul-87 14:39:13 EDT
From:      jcollas@XN.LL.MIT.EDU (Juan Collas)
To:        comp.protocols.tcp-ip
Subject:   SNAP Protocol


People,

I've been reading the ULANA spec, and am curious about the SNAP
protocol, mentioned twice but never defined.  What is it?  There's
supposed to be an RFC for it, but I can't find that either.

(ULANA is the Air Force's Unified LAN Architecture Phase I.)

Any knowledgeable types out there?

	-Juan Collas, MIT Lincoln Labs

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Jul-87 21:13:36 EDT
From:      tomlin@hc.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  Wollongong TCP/IP for VAX/VMS

in article <8707081702.AA03732@topaz.rutgers.edu>, ron@TOPAZ.RUTGERS.EDU (Ron Natalie) says:
> 
> Would you like to propose an alternative.  The other major
> commercial offering (DTC/COMPION/GOULD/Whatever) ACCESS for
> VMS is WORSE.

What about Fusion TCP?  It seems to work OK (they have a couple
problems, such as no name server yet).  And at least you can talk to
reasonably intelligent technical people instead of the Wollongong
marketing staff.  It's also more resonably priced.

-- 
Bob Tomlinson -- tomlin@hc.dspo.gov  --  (505) 667-8495
Los Alamos National Laboratory  --  MEE-10/Data Systems

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Jul-87 22:27:37 EDT
From:      melohn@SUN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: SNAP Protocol

Refer to pages 12-13 of the latest "Assigned Numbers" RFC1010. I'm
in the process of revising RFC948 to include the information about SNAP
encoding worked out last fall in Monterey.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Jul 87 17:09:42 P
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Israel Tcp/Ip Plans

                         Conversion Plans
                        from RSCS to Tcp/Ip
                    for Israel Academic Network

                                by
                         Henry Nussbacher
                          July 7th, 1987



Table of Contents
Acknowledgments

I.   Reasons for conversion
     A. Background
     B. Reasons
II.  Why Tcp/Ip and not something else?
     A. SNA
     B. DECNET
     C. ISO
     D. TCP/IP
     E. Caveats
III. What will it cost?
     A. Alternatives
        1. High speed LAN (Ethernet)
        2. BSC driver for leased lines
        3. Tcp/Ip "black" boxes
     B. VM
     C. MVS
     D. Unix
     E. VMS
     F. Primos
     G. NOS
     H. Intercampus
     I. Total cost for all systems
IV.  Timetable for conversion
     A. Stage I   - The test
     B. Stage II  - Tcp/Ip for everyone
     C. Stage III - The Tcp/Ip<->RSCS gateway
     D. Stage IV  - Conversion to ISO
V. Appendix 1 - List of Israeli EARN nodes
   Appendix 2 - Cost of connecting PC's to a Tcp/Ip Network
   Appendix 3 - List of Tcp/Ip software and hardware vendors
   Appendix 4 - The Tcp/Ip Reference Model
   Appendix 5 - Glossary of acronyms
   Appendix 6 - References
   Appendix 7 - EARN Migration Plans
   Appendix 8 - Israel viewpoint on EARN Migration Plans


Acknowledgements:

    Many people  have provided  valuable input  but there  are a few
whom I wish to single out:

John Klensin   - MIT
Mike Kramer    - Nynex
Scott Brim     - Cornell University
Marshall Rose  - Northrop Research
Dan Lynch      - ACE

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

I. REASONS FOR CONVERSION
   ======================

I.A: Background:

    This report is based on meetings held by the Israeli  University
Telecommunications  Subcommittee.   Various  pros  and  cons  of the
following proposal were  discussed and argued.   All members of  the
Telecommunications Subcommittee have reviewed this proposal and have
stated their views to me via electronic mail.

I.B: Reasons:

    Quite often people ask, "Why  do we need to change  something if
it works  perfectly and  gets the  job done  correctly?"  This  is a
valid question and  this section will  answer it.  Currently,  there
are 43 computers connected to the Israeli section of EARN  (European
Academic  Research  Network  -  sister  network of Bitnet).  The six
operating systems are:

VMS        14
Unix       11
VM          8
NOS         4
MVS         3
Primos      3
          ---
Total      43

    The protocol in use  today is known as  RSCS, also known as  NJE
(Network Job  Entry).  This  protocol was  developed within  IBM and
resulted in the creation of  VNET - IBM's internal use  network that
currently numbers 2297 nodes (as of Nov 26th 1986).  The reason  for
its successful growth within IBM was for one reason: its simplicity.
One could install RSCS in one hour on a VM system and be talking  to
another node within the same amount of time.

    RSCS provides two protocols for communication: file transfer and
interactive messages.  There  is no remote  login (this is  supplied
within  Vnet  by  a  parallel  network  known  as PASSTHRU), no mail
protocol, no  topology management  and very  little network control.
In addition,  when IBM  released RSCS  to the  public in 1972 (along
with  VM  Release  1),  it  only  allowed  for the connection of IBM
operating systems (VM, MVS, DOS) and no other operating system.   As
Bitnet  started  to  develop,  various  universities  developed  NJE
simulators for their own operating systems.  Urep (for Unix systems)
was developed at Penn State  University, jnet (for VMS systems)  was
also developed at Penn State  University, and the author later  sold
the  software  to  Joiner  Associates  for  a  healthy profit.  Some
vendors have taken it upon themselves to develop the NJE emulation -
as Prime has recently announced for their Primos operating system.

    Over half the nodes in Israel only have a limited access to  the
NJE protocol.  These nodes cannot send any interactive messages  and
some of them  cannot send any  files other than  RFC822 (Request For
Comments #822) mail.  Therefore, Israel currently has the  situation
where some  nodes have  greater "connectivity"  to the  network than
others.  That is one of the problems that needs to be resolved.  All
nodes in  the network  should be  able to  supply the  same level of
service to their users - no matter where that node happens to be  in
Israel.

    Even if the network topology was rearranged so that only a  very
few nodes with  limited software were  to be assigned  the status of
end-nodes,  we  would  still   have  the  problem  of   the  limited
functionality that RSCS provides.  Users have been asking for remote
login for a long time and this can currently only be provided to  VM
sites and at a high cost to network performance.

    In the  area of  performance, RSCS  loses out.   First of all it
uses a BSC protocol that requires an acknowledgement for every block
received over a link.  This requires line turnaround time and a loss
of throughput.  A full duplex protocol (HDLC) over our existing 9600
baud lines  would effectively  increase throughput  by approximately
30%-40%.   In  addition,  RSCS  does  not  do any sort of dynamic or
adaptive routing.  If  a link goes  down (which we  are already very
familiar with),  then data  communication to  that node  is shut off
completely.


II. WHY TCP/IP AND NOT SOMETHING ELSE?
    ==================================

    There  are  other  networking  protocols  that  exist and I will
review three of them: SNA, Decnet and ISO.

    II.A:  SNA:  It  is  interesting  to  note  that IBM's strategic
networking system  is not  used for  its own  internal network,  but
instead RSCS is  used.  IBM has  been trying to  convince the people
within its own network  that SNA will be  "good" for them, but  till
this date  nothing has  happened.  In  a lecture  by Tom Piatkowski,
currently  at  SUNY  Binghamtom,  but  more  importantly  one of the
original architects of SNA, he  noted that SNA was designed  for the
central management of a small  network and not for a  globe spanning
network.   SNA  excels  in  managing  a  campus  network;  a network
confined to a limited number of buildings and other small geographic
entities.

    A  recent  internal  memo  within  IBM  detailed the performance
tradeoff between using SNA and RSCS  over a 9600 baud line or  CTCA.
The file transfer times were almost identical for both protocols but
the SNA system took 40%-60%  more CPU time to execute  the transfer.
This  is  understandable  when  one  looks  at  the size of the RSCS
program compared to the size of the RSCS/SNA/VTAM program.

    SNA's other major problem is  also spelled with 3 letters:  IBM.
Other operating systems may  create gateways from their  networks to
IBM's, but only  a small number  have done so  to date and  the only
places that  have installed  these gateways  are those installations
that had to.  No installation to my knowledge has planned a  network
from the  start with  the assumption  of using  SNA gateways to four
non-IBM operating systems (three of which do not exist yet).

    Europe and for that matter  the rest of the world,  have decided
that IBM is not to be followed with their networking protocols.  For
that reason they have created the ISO, which I will get to shortly.

    II.B: DECNET: Much of what has been discussed in the section  on
SNA pertains also to DECNET.   VMS, Ultrix and TOPS-20 are  the only
operating  system  that  can  use  Decnet  and  three  months   ago,
Technology  Concepts  Inc.  announced  CommUnity,  which allows Unix
systems to participate in  a DECNET environment.  For  our purposes,
DECNET  only  supports  two  of  our  operating systems along with a
gateway to SNA - exactly the same numbers that SNA claims.

    II.C:  OSI:  The  International  Standards  Organization   (ISO)
created the Open Systems Interconnect (OSI) Reference Model  because
they saw that a uniform approach needed to be created for the entire
world.   In  five   years  time,  I   expect  we  will   see  4  OSI
implementations: VM, MVS, VMS and Unix.  I do not see that a NOS  or
Primos implementation will be available within that time frame but I
am always ready to be pleasantly surprised.  As of the end of  1986,
there  were  only  three  X.400  implementations available (the mail
protocol  of  OSI)  -  all  of  them  on an unofficial basis.  It is
important to remember that X.400 is not an OSI protocol but rather a
CCITT protocol that  the ISO is  considering to be  part of its  OSI
protocol suite.  No  FTAM (file transfer)  or Rlogin (remote  login)
implementations have been heard of.  Clearly, people are working  on
developing the  OSI protocols  but we  are currently  looking for  a
networking standard that will last us through 1992.

    It is interesting to note that OSI is not a protocol but  rather
a reference model that  provides for several families  of standards.
All that one  has to do  to become an  "OSI product" is  to document
what your  software does  in terms  of the  reference model.  DECNET
claims that DNA is an OSI product  as IBM claims that SNA is an  OSI
product.  Different vendors will  interpret the OSI reference  model
differently and in that case we will have many OSI products,  unable
to talk  to each  other.  That  is why  the NBS  (National Bureau of
Standards) in  the United  States has  created OSINET  - a  test bed
where vendors can try  out their software to  see if their OSI  will
talk to someone else's OSI.

    II.D: TCP/IP: So what is so great about Tcp/Ip?  For one, it  is
the oldest networking protocol around, predating DNA and SNA.  There
are 124 different  Tcp/Ip implementations that  run on 28  different
brands  of  hardware  (see  Appendix  3).   In addition there are 23
companies that make hardware  (boxes or cards) that  connect various
computers  to  a  Tcp/Ip  network.   If  we  ever  need to add other
operating  systems  to  our  network  (example:  MS/DOS), Tcp/Ip can
handle it.  Tcp/Ip works  in full duplex so  a leased line is  fully
utilized.  Arpanet and Csnet in the United States use it, as well as
numerous  individual  installations  in  Europe.   It provides three
standard  applications   protocols:  SMTP   (Simple  Mail   Transfer
Protocol), FTP (File Transfer  Protocol) and TELNET (Remote  Login).
All operating  systems in  Israel have  Tcp/Ip implementations  (NOS
Tcp/Ip to be available from CDC - April 1987).

    Tcp/Ip  can  run  on  leased  lines  (9600 baud up to T1 speed),
Ethernet, X.25 circuits, Pronet, etc.   It is more in the  spirit of
the OSI reference model than SNA or DECNET since the physical and at
least part of the link layer can be swapped out and substituted  for
with no change in the transport or session layers.

    Some Israeli universities have  already made a heavy  commitment
to  Tcp/Ip.   Hebrew  University,  Ben  Gurion  University, Weizmann
Institute of Science and Tel Aviv University have most of their  own
computers interconnected via Tcp/Ip.  By installing a Tcp/Ip network
we  will  be  gaining  access  to  the  many  Sun workstations, Lisp
machines  and  other  unique  hardware  that  exists at each campus.
Currently,  these  machines  are  available  locally  at  individual
campuses  via   local  Tcp/Ip   networks.   Since   Machba  (Israeli
InterUniversity Organization) has  been considering the  purchase or
sharing of  a Cray,  it should  be noted  that Cray  has developed a
Tcp/Ip implementation for their Unicos operating system.

    Most importantly,  the DOD  (Department of  Defense) has  stated
that it intends to convert to ISO standards when such standards  are
made available.  To this  end, the Northrop Research  and Technology
Center has recently introduced RFC983 - which defines a strategy for
conversion in an evolutionary  manner as opposed to  a revolutionary
manner.  They  offer a  free ISO  Development Environment  that they
have developed (written in C)  that currently runs on Unix,  VMS and
PC/DOS.

    It is clear that the conversion route from Tcp/Ip to ISO  (since
they are so similar and parts of ISO are drawn directly from Tcp/Ip)
will be the smoothest.  The  alternatives before us are few:  either
to sit still and continue to use the RSCS protocol for many years to
come or to convert now to Tcp/Ip, under the assumption that it  will
be  replaced  by  the  ISO  suite  of  protocols  when  they  become
available.  It is my personal  feeling that the upper layers  of the
ISO  protocol  (levels  5-7)  are  at  least  5-8  years  away  from
implementation.

    II.E: Caveats: There is also a negative side to Tcp/Ip.  Certain
implementations are buggy and will require a large amount of systems
programming   intervention.    We   will   try   to   avoid    those
implementations but it should be known from the start that Tcp/Ip is
not bug free (neither is  any other networking or operating  system)
and  we  may  run  into   a  glitch  along  the  way   with  certain
implementations.

    The implementations that  do work properly  may be lacking  some
feature  that  we  will  realize  later  on  that  we  need.   It is
impossible to know at this stage  of the game what all the  features
that are in  Tcp/Ip (i.e. dynamic  routing, adaptive routing,  ICMP,
UDP) that will be needed.

    Tcp/Ip lacks certain features that we may need to develop in the
future (but do not exist today).  These include: accounting -  there
is no  facility to  gather statistics  on path  usage, data transfer
rates, etc.; authentication and access control - suppose we wish  to
limit data  transfer limits  for students  - currently  there is  no
mechanism  to  accomplish  this  with  Tcp/Ip.  The Arpanet realizes
these requirements and  has informed vendors  to be prepared  in the
future to include access-control and accounting machanisms in  their
gateways.

    Most of the assumptions for a smooth conversion depend that  the
Tcp/Ip network and RSCS network work in parallel for a period of two
years.  This involves an added cost that needs to be considered.

    Lastly, a network of this nature needs staffing.  It doesn't run
by itself  and it  doesn't fix  itself.  In  general, you  need more
staff  to  run  a  network  than  not  to  run  a network.  Of the 6
operating systems in Israel, four have sufficient systems  expertise
scattered through  the various  universities.  The  two systems that
lack "networking & system hackers" are Primos and VMS.  All computer
centers should be prepared to have one full-time person whose  major
responsibility is the running of their LAN.


III. WHAT WILL IT COST?
     ==================

... this section removed for EARN and Bitnet distribution ...


IV. TIMETABLE FOR CONVERSION
    ========================


IV.A: Stage I:

    This stage involves  the interconnection of  2 or more  separate
Tcp/Ip  LANs.   Currently,  there  are  Tcp/Ip  networks  at  Hebrew
University (CS Department only), Tel Aviv University (CS  Department
only),  Bar  Ilan  University  (CS  Department  only)  and  Weizmann
Institute of Science (CS Department and Computer Center).  There are
two alternatives to accomplish this:

    A) VM to VM:  The Wiscnet package comes  with a BSC driver  that
can run a point to point leased line.  All 4 Universities  mentioned
above have VM systems but currently only one of them runs Wiscnet.

    B) Tcp/Ip  boxes (Bridge  GS/3M): This  would allow  any of  the
current LANs mentioned above to interconnect.

... two paragraphs removed for EARN and Bitnet distribution ...

    Synopsis:  identify  potential   and  willing  sites   with  the
necessary  software,  then  order  necessary  hardware.   This stage
should be completed no later than September 1987.


IV.B: Stage II:

    This stage is just an extension of Stage I. All 43 Israeli  EARN
sites should be running Tcp/Ip on their system and a parallel Tcp/Ip
network should exist alongside the current RSCS network.  This stage
will be the one to work out all the bugs between the various systems
(inter-machine translation  problems, performance  and optimization,
etc.)

    While this work is going on, the sites from Stage I should start
experimenting with  using their  local Tcp/Ip  services to  send and
receive data from the  RSCS EARN network.  Makeshift  solutions will
be made and the specific problems and necessary global solutions for
Israel will be identified in this stage.

    This stage depends on the  fact that alternate lines will  exist
for each of the  43 computers currently connected.   These alternate
lines can  be either  9.6Kb or  64Kb Sifranet  lines.  The important
point in this matter is that alternate lines have to exist for  this
to work.

    Synopsis:  Order  equipment  for  all  43 Israeli nodes, install
software and hardware.  This stage should be completed no later than
June 1988.

IV.C: Stage III:

    This is the final stage.   It involves the disconnection of  the
9600 baud  leased lines  and the  end to  the RSCS  network that  is
currently  in  place  in  Israel.   But  before  this can be done, a
gateway needs to exist at Tel Aviv University (our EARN gateway  for
the country) that  will send and  receive Tcp/Ip datagrams  from one
side and send and receive  RSCS files and interactive messages  from
the other.  It will be up  to each site to decide whether  they wish
to use the new Tcp/Ip functions (i.e.  SMTP or FTP) or whether  they
wish to take their old  RSCS user interfaces and make  the necessary
modifications (on a  local basis) so  that they can  communicate via
the  Tcp/Ip  network.   It   will  not  be  Tel   Aviv  University's
responsibility to modify every user  program on all 43 systems  that
currently communicate with EARN.

    It  will  be  Tel  Aviv  University's responsibility to design a
gateway with the following capabilities:

    FTP: If a file arrives  via EARN, destined for an  Israeli user,
then an FTP transaction should be created for delivering the file to
the user.  In certain  cases, FTP to a  system may not be  possible.
In that case, TAU must provide the necessary modifications for  that
system so that they can receive FTP transactions.  An example  would
be  a  file  destined  to  a  VM  site.   Since FTP requires a write
password  to  the  person's  disk  -  a  vanilla FTP would not work.
Possible alternatives might be: a)  sending the file to an  FTP sink
user at the intended  node, along with a  mail file to the  intended
user informing him that a file has arrived and can be received  from
his local FTP sink user; b) modifications to Wiscnet FTP that  would
allow FTP to the user's VM spool (preferred solution).

    The  reverse  also  needs  to  be  handled.  If a user in Israel
wishes  to  send  a  file  to  a  user in Germany via EARN, then the
gateway  at  TAU  must  accept  the  FTP request and receive all the
intended packets on behalf of the user in EARN.  It will then  issue
a sendfile on the user's behalf, counterfeiting the original  user's
id and  nodename instead  of its  own.  There  are many details that
need to be worked out for this gateway (such as what format to  send
data in: netdata, disk dump, punch, print, specifying RSCS dependent
options on the FTP request - like priority, class, forms, etc.)

    SMTP: Israel will register itself as being a domain of AC.IL and
that  all  mail  destined  for   this  domain  should  be  sent   to
MAILER@TAUNIVM.  This  mailer will  then deliver  the mail  via SMTP
methods rather than  RSCS methods.  The  reverse must also  be taken
care of.   This area  is considered  to be  the easiest  since other
installations throughout the world have already tackled this problem
and have come up with software solutions that we can use.  It should
be noted that Arpanet has already assigned an upper level domain  to
Israel (.IL) and that there  is already a node at  Hebrew University
listed  as  a  host  in  Arpanet  (HUJI.AC.IL).   It would then be a
trivial matter to  define all other  hosts in Israel  in the Arpanet
hosts  table,  thereby  giving  us  equal  access to Bitnet (via the
planned  gateway  at  TAU),  and  via  the X.25 link to Arpanet from
Hebrew University.

    TELNET: This  will not  be supported  in the  direction of  EARN
since it  is not  supported today.   Users will  only be  allowed to
TELNET within Israel.

    RSCS Interactive messages: This is  one area that we may  not be
able to implement.   The ISO protocols  do not support  this kind of
facility and neither does the Tcp/Ip protocol.  We will only be able
to determine  whether we  can implement  this near  the end of stage
III.  A  while back,  Arpanet implemented  a SEND  protocol that was
fairly similar  to RSCS  interactive messages.   It required  a SEND
server at the  origin and destination  sites.  This service  did not
catch on with  Arpanet users since  they found it  a bother to  know
whether a  user was  logged on  at the  time.  Several people within
Arpanet  have  indicated  that  the  SEND  protocol  is very easy to
implement since  it never  waits for  an acknowledgement  but rather
just sends a datagram and exits.  We may be able to use some of  the
early Arpanet work but it will have to remain as a low priority work
item during the general timetable.

    It should be noted that  some of this development work  could be
done in the  framework of a  graduate student project.   Ariel Frank
(Bar Ilan University)  has indicated that  he has graduate  students
that he could assign with subsets of the above stated work.  Various
other universities  may also  have graduate  students that  could be
utilized to  develop certain  components that  have been  delineated
above.

    Synopsis: A lot of software development should have already been
started by the  end of Stage  I. This stage  should be completed  no
later than January 1989.


IV.D: Stage IV:

    This stage involves the conversion to ISO.  As solutions  become
available on Arpanet (i.e.  RFC983;  see Appendix 6), we will  adopt
them.  I foresee this stage lasting over a period of 2-3 years after
January 1989.  It is quite possible, that development projects  will
be assigned to Israel (i.e. from  IBM, CDC, DEC, etc.) in this  area
over the next five years.


V. APPENDIX 1: List of nodes in Israel
   ===================================


... this section removed for EARN and Bitnet distribution ...


APPENDIX 2: Connecting PC's to the Tcp/Ip network
=================================================

... this section removed for EARN and Bitnet distribution ...


APPENDIX 3: List of Tcp/Ip Hardware and Software Vendors
========================================================

... this section removed for EARN and Bitnet distribution ...


APPENDIX 4: The Tcp/Ip Reference Model
======================================

Applications Layer    (7)
Presentation Layer    (6)
Session Layer         (5)
Transport Layer       (4)
Network Layer         (3)
Data Link Layer       (2)
Physical Layer        (1)


APPENDIX 5: Glossary of acronyms
================================

Application Level:

FTP    - File Transfer Protocol - transfer of files and directories
         between computers
TELNET - Virtual Terminal Protocol - interactive remote logon
SMTP   - Simple Mail Transfer Protocol - RFC822 mail
BSMTP  - Batch Simple Mail Transfer Protocol
NFS    - Network File System - SUN protocol for accessing remote
         files

Transport Level:

TCP  - Transmission Control Protocol - sliding window protocol,
       connection oriented, flow control, multiplexing

Network Level:

IP   - Internet Protocol - packet addressing and fragmentation
UDP  - User Datagram Protocol - connectionless service for host to
       host comunications
ICMP - Internet Control Message Protocol - reports on transmission
       errors, flow control, first-hop gateway redirection and
       routing information
ARP  - Address Resolution Protocol - converts 32-bit Internet
       addresses to 48-bit Ethernet addresses.
EGP -  Exterior Gateway Protocol - used to exchange information
       between gateways

Data Link Level:

DLP  - Data Link Protocol (also known as DLAP - Data Link Access
       Protocol) - provides connectionless service for sending and
       receiving datagrams


APPENDIX 6: References
======================

1) RFC942 - Transport Protocols for the Department of Defense Data
   Networks; Feb 1985

2) RFC983 - ISO Transport Services on Top of the TCP; Northrop
   Research; April 1986

3) RFC985 - Requirements for Internet Gateways; NSF; May 1986

4) Tcp/Ip Vendor's Guide; SRI; Feb 1987

5) DDN Protocol Handbook; SRI; Dec 1985

6) Ethernet: Distributed Packet Switching for Local Computer
   Networks; Metcalfe and Boggs; ACM Communications, July 1976

7) Introduction to Local Area Networks; DEC; 1982, EB-22714-18

8) Proceedings of Campus Network Plans and Pc/Ip Workshop;
   University of Maryland; Dec 1985

9) Computer Networks for Scientists; Jennings, Landweber, Fuchs,
   Farber, Adrion; Science; Feb 28, 1986

10) Notable Computer Networks; Quarterman and Hoskins; ACM
    Communications, Oct 1986


APPENDIX 7: EARN Migration Plans
================================

EUROPEAN ACADEMIC RESEARCH NETWORK


The migration of EARN to use ISO protocols,
summary of the proposed strategy and tactics.
Subject to ratification by the EARN Board of Directors and further study

                                                       issued by
                                                       P Bryant
                                                       20 April 1987

_______________________________________________________________________


1 Summary

EARN is determined to migrate to use ISO protocols as soon as possible.

It is vital that during this migration there is no significant loss of
service to the users.

Until recently there have not been the products available to start a
migration. There are now a number of developments which suggest that the
first stages of a migration could now be undertaken. The completion of
the process will take several years.

The EARN Board of Directors set up a working party to define the
migration path which is just concluding its work. This paper is  a
summary of their report. The full report is now under discussion.


2 Why migrate?

There are three reasons for EARN wishing to use ISO protocols:

- EARN had to obtain permission from the various national regulatory
authorities in order to operate. This was because it infringed the PTT
monopolies in some countries. CEPT, the European advisory body for such
matters, agreed to recommend EARN should be permitted as long as they
migrated to ISO protocols by the end of 1987.

- EARN uses the fairly primitive IBM NJE protocols which provide a store
and forward network for file transfer and mail. The use of ISO protocols
would provide a broader range of services. ISO protocols are expected to
be available under most systems whereas NJE is restricted to the more
popular ones.

- All the west European countries (and many others) are expected to base
their academic networking on ISO protocols. EARN must cooperate and
interwork with these networks.


3 The state of protocols

The CCITT X.25 protocol is widely available but only in its 1980
version. The 1984 version is required for the support of ISO protocols.
The PTT's planed dates for the 1984 version are not yet clear. Various
private switch suppliers now provide it.

The X.400 mail protocol is available in a number of experimental or
pilot versions. The use of this protocol is likely to expand rapidly as
the PTTs provide services based on it in the near future.

FTAM (the ISO file transfer protocol) is only now becoming stable and
implementations are not expected for some time.

VTP (virtual terminal protocol) and JTP (job transfer protocol) are both
unstable and implementations are not expected for a long time.


4 The parts of EARN

EARN can be regarded as two parts - the national parts and the
international ones.

The migration of EARN within a country must be undertaken in close
cooperation with other national activities and will therefore not be
directed centrally.

The migration of the international parts will be directed by the EARN
Board. All the international EARN nodes are IBM ones. This is the
principle subject of this paper.

It is essential that the international and national migrations are
carefully coordinated.


5 The first stage, strategy

The only ISO protocol that can currently be adopted is X.25.

The strategy is to operate the IBM NJE protocol over X.25. This can be
achieved using IBM products. The users will not need to be aware of the
change since the strategy will not alter the services provides or the
interface to the user.

The use of NJE over X.25 demands the use of X.25 permanent virtual
circuits. These cannot be provided internationally by the PTTs and
therefore EARN will have to provide an interim  private X.25 network.
This has the secondary advantage that X.25 (1984) can be used which is
not currently available from the PTTs and this needed to support the
higher level ISO protocols.


6 The first stage, tactics

A survey has shown that private switches which provide permanent virtual
circuits and X.25 1984 are available.

The number of switches and their location depend on the cost of switches
and the cost of lines. An incomplete study suggests that initially there
should be two switches- one serving the north of Europe and one the
south. There will need to be some relocation of lines but this is
expected to be done over a fairly long period of a year.

It is intended to use the X.121 address scheme. This defines the first
four digits of an address. Eight digits will remain for use within a
country which will be allocated according to national needs although it
is suggested that four digits define a site and four for use within a
site. A two digit subaddress will not be policed by the network.

Initially only a few sites with good networking expertise will be
connected. The rest of the international sites will be migrated at a
later date and in some cases when lines are relocated.

A few sites will need additional software which may also cause a slight
delay.

The EARN services will be enhanced by the addition of the X.3, X.28, and
X.29 services on some sites. This will not be very useful until the
national parts of EARN have migrated to X.25 or gateways are provided to
other X.25 networks.

The tactics within a country will be the responsibility of the country.
Some countries will want to migrate in step with the international parts
of EARN. Others will want to wait. Others may want to provide gateways
and relays to existing or proposed national networks.

The use of Coloured Book protocols and DECNET will be allowed for an
interim period to meet the needs of some specific groups of users. This
will allow good connectivity between Ireland, the UK, and some other
sites who use Coloured Books. DECNET is popular with the astronomy,
space physics and high energy physics communities.


7 The second stage, strategy

The first higher level ISO protocol to be promoted will be X.400 mail
protocol.

Some countries are expected to migrate with the international part of
EARN. They will be installing switches for this purpose. These switches
may be used to enhance the international parts of EARN and require some
change to the EARN topology.


8 The second stage, tactics

There are a number of X.400 systems now available.

In particular the IBM Heidelberg system will operate on IBM VM systems
and so it will be mounted on many of the international nodes. This
system has the property that parts of the system can be located remotely
over the NJE network thus allowing greater penetration of EARN by X.400
than the extent of the X.25 network would suggest.

Other X.400 systems, such as EAN, are expected to interwork with the
Heidelberg one and recent tests are encouraging. These will be of
greatest interest within a country.

Some countries are expected to be part of the EARN address space as they
migrate. Other will have different schemes and gateways and relays will
be provided to maintain a service. Various promising products are in
existence or being produced.

The most important relay will be between X.400 and RSCS mail systems. A
suitable product is being produced in Germany.


9 The fourth stage, strategy

The use of NJE, DECNET, and Coloured Book protocols will be phased out
leaving a pure ISO network. At this stage it will be possible to use the
public networks.

The removal of these protocols depends on the provision of FTAM (the ISO
file transfer protocols) which should be available in a year or two.


10 The fourth stage, tactics

Currently there are no suitable versions of FTAM available and no firm
indication of dates. EARN will wait for suitable products and promote
them as soon as possible.

The fourth stage will require further study. It is unlikely to be
concluded before 1989.


11 Time scales

The international switches plus a few connections could be provided by
the end of 1987. The complete migration of the international part of
EARN to X.25 will take to the middle or end of 1988. NJE services must
be provided immediately.

X.400 can be provided on some nodes by early in 1988 with all
international nodes operating it at the end of 1988.

The use of Coloured Book and DECNET protocols will only be provided
where needed. Planning will be on a bilateral basis.

The migration of countries has not yet been studied in detail. There
will be gateways and relays to some existing X.25 national networks at
the end of 1987. a small number of national networks within the EARN
address scheme are expected towards the end of 1988.

Implementations of FTAM are expected in 1988 or 1989.

NJE will be phased out as soon as FTAM is proved to be able to offer a
comparable service. Manufacturers plans and timescales are not
available.


12 Standards

EARN will follow the emerging functional standards being elaborated by
CEN/CENELEC. EARN is also following the activities of RARE. This is
important to ensure that EARN can interwork with other academic networks
which are all expected to follow the same standards and functional
standards.

It must be noted that EARN is a service provider and does not intend to
take part in standards activities as a primary activity. In addition,
EARN does not intend to develop products but to use those provided by
others.


13 Conclusions

EARN is moving towards the use of ISO protocols as fast as possible. The
main delay is caused by the lack of implementations of protocols which
is not surprising considering the unstable nature of some of them.

EARN is dedicated and will remain dedicated to providing the best
possible service to the European academic and research community.


APPENDIX 8: Israel viewpoint on EARN Migration Plans
====================================================


Date: July 1, 1987

    This section will address some of the points raised in the  EARN
Transition paper (April 20, 1987) by Paul Bryant (Appendix #7).   In
order to follow the points made, it is advised to have a copy of the
EARN Transition paper available.

    1) Israel is determined to migrate to the ISO protocols.

    2)  Israel  agrees  entirely  with  the  need to abandon the NJE
protocols and adopt the OSI international standards.

    3)  The  1984  X.400  standard  finally  has  a few experimental
implementations available.  IBM's announcement of X.400 support  for
MVS systems fails to mention that availability is 3Q88.  As yet, IBM
has not announced  X.400 support for  VM.  We also  realize that ISO
has not adopted the CCITT X.400 standard and that the newly  revised
1988 X.400 standard  will be (on  certain levels) incompatible  with
the 1984 version (i.e. mailing and distribution lists).  If we  take
X.400 as an example,  we can assume that  it takes 4 years  from the
time a standard  is finalized until  the first half  dozen supported
implementations appear in the marketplace.  OSI's timetable in  1985
stated that  CASE, FTAM,  JTM, MOTIS  and VTP  (the top  application
level)  were  all  to  become  IS (International Standards) by 1987.
Unfortunately, all of  them are still  DP or DIS  and some (JTM  for
example) are therefore approximately 4 years behind schedule.

    ISO has also published a timetable for the Management  Framework
which includes standards for fault management, accounting, security,
configuration, etc.  Their initial timetable states IS completion by
4Q90.  If we  assume that ISO  will meet this  deadline then we  can
only hope to see the  first half dozen supported implementations  of
the *complete* OSI model by 1994  (if we are to use the  X.400 model
as an example).

    It is the period of the next 7 years that the national  academic
network of Israel will follow an alternate path to the ultimate  OSI
solution.

    4) Israel will be  a full partner in  all EARN decisions on  the
international segment of the  network.  It is Israel's  intention to
implement all EARN recommendations for its international link.

    5) Israel will participate  in the interim private  X.25 network
that EARN wishes to construct between the various country gateways.

    6) It is stated in this section that each country is responsible
for what occurs within its own country.  "Others may want to provide
gateways and  relays to  existing and  proposed national  networks."
Ireland and England are mentioned as two examples.  Israel will fall
into this category.

    7) Agreed.

    8) As X.400  products become available  we will implement  them.
As EARN proceeds with X.400, so too shall Israel on an international
level.

    9) Agreed.  DECNET  and Coloured Book  protocols will be  phased
out as  ISO protocols  become available.   We are  just not quite as
optimistic ("should be available in a  year or two") as EARN is  and
therefore see the conversion to  Tcp/Ip as a strategy for  supplying
all the services that ISO is planning, on an interim basis.  If  for
some reason  the ISO  deadlines slip,  we will  continue to function
with our national Tcp/Ip  network until the necessary  protocols are
available.

    10) It is stated in the Transition paper that the conversion  is
"unlikely to be concluded before 1989."  The OSI FTAM standards (all
4 parts: 8571/1,  8571/2, 8571/3, and  8571/4) are still  DIS (Draft
International Standard), the same status they have been since  1986.
If they do turn to IS before the year is over, I do not foresee more
than 5-6  supported implementation  available before  1990.  A  more
realistic timeframe would be 1992.

    11) Israel  views these  timescales to  be extremely optimistic.
When  dealing  with  existing  services  (file transfer, interactive
messages and mail) currently provided by EARN, it is very  important
to have contigency plans in case of unforeseen delays.  We view  the
conversion  to  Tcp/Ip  as  an  insurance  policy that starts paying
dividends today.

    12) Agreed.

    13) "EARN is moving towards the use of ISO protocols as fast  as
possible, the main delay is caused by the lack of implementations of
protocols which is not suprising considering the unstable nature  of
some of them".  That is  EARN's conclusion.  Israel is committed  to
ISO conversion as the standards become available.  We see Tcp/Ip  as
an interim solution over the next 7 years.
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 87 23:21:02 GMT
From:      hoptoad!gnu@ucbvax.Berkeley.EDU  (John Gilmore)
To:        tcp-ip@sri-nic.arpa
Subject:   X.400 gateways to RFC822 mail systems
The messages on EARN and Israeli conversion reminded me of an issue
that's worth airing.  The early efforts to provide X.400 mail gateways
are not very encouraging.  Here is a message I received from such
a gateway at AT&T:

	Return-Path: <ihnp4!ihlpa!sft>
	Received: by hoptoad.uucp (1.1/SMI-3.0DEV3)
		id AA21284; Thu, 12 Mar 87 20:24:45 PST
	From: ihnp4!ihlpa!sft
	Message-Id: <8703130424.AA21284@hoptoad.uucp>
	Received: by ihnp4.ATT.COM id AA16275; 12 Mar 87 08:07:23 CST (Thu)
	Message-Version: 2
	>To: /addr=ihnp4!hoptoad!gnu
	Date: Thu, 12 Mar 1987 08:06 CST
	Message-Service: Mail
	Message-Protocol: EMail
	End-Of-Header: 
	Email-Version: 2
	X-Postmark: scott.thompson attbl ih5c422 55669 3129792594 ihlpa!sft
	To: hoptoad!gnu
	Subject: Re: Wanted: agef program
	Ua-Message-Id: <post.sft.Thu, 12 Mar 1987 08:03 CST>
	End-Of-Protocol: 

		Thank you for the reply, but I already received a copy.

			THANKS :-)

To me it looks like a core dump of a binary message header.  
I asked Mark Horton about this and he said it was from an X.400
gateway and that it was unlikely that it could get fixed, e.g. to
remove all the trash headers.  This must be political rather than
technical since even I can write a sed script that will fix this message
right up, and another one to insert meaningless headers on messages
going the other way.  It strongly reminds me of Geoff Collyer's joke
messages that poke fun at RFC822 by inserting silly header lines.
But I think these guys are serious, and they're The Telephone Company.
-- 
{dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu	       gnu@ingres.berkeley.edu
Alt.all: the alternative radio of the Usenet.
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jul-87 03:44:20 EDT
From:      dpk@BRL.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Internet Uselessness

Well, I am again trying to use the Internet to accomplish real
work and finding it almost impossible due to the almost none-existent
throughput.  IETF*/BBN/DCA/DARPA have yet to be able to solve the
performance problems that have been plaguing the Internet for months.
There was a time when I could easily sit here at BRL on the East Coast
and manipulate files and programs at Berkeley with ease.  This is no
longer possible to do reliably.  It has gotten to the point now that
phone calls at 1200 baud will get more work done.  I am getting ready
to dust off my UUCP...

Lest some of you misunderstand, there are parts of the Internet
that are reasonably healthy, such as the MILNET proper, which
while its had its problems (e.g. C300 software that falls on its
face), in general works fairly well.  But the MILNET is only a
part of the much larger Internet.  The MILNET alone is of little
use to us if we cannot talk successfully to the rest of the Internet.

Under one hat I am a member of IETF so I am aware of the nature of many
of these problems.  But under my other hat as a simple "user" of the
network, I don't care why its broken, it just needs to get fixed.
IETF understands many of the problems, but seems to lack power to get
those with the resources to take action.  There are ways to fix the
network but it takes money and priority on the problem. This need to
happen soon.  The Internet is needlessly getting a black eye because
its not working.

Telling me that the load went up and therfore performance went
down is no excuse.  If we expected to be successful, we should
have expected the load.

The Internet is too important to all of us (including the military)
to let this continue.  Do DCA/BBN/DARPA have any comments on this?
Who do we have to push to get this fixed?

Cheers,
	-Doug-

  Doug Kingston
  Advanced Computer Systems Team
  Systems Engineering and Concepts Analysis Division
  U.S. Army Ballistic Research Laboratory

* - Internet Engineering Task Force

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jul 87 09:06:10 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Internet Protocol #77

    Here at the CSNET CIC we're collecting some statistics to help us
figure out why the CSNET relay is in the top-10 traffic list.

    One of the things we've done is to start tracking the protocol
field in each IP header (to show us which protocols are causing most
of our traffic).  And before I've even analyzed our data I've found a
small anomaly.

    It clearly isn't causing our traffic problems, but we're receiving
packets with the IP protocol field set to 77 decimal.  So far it is 21
packets in the past 16 hours).  According to RFC 1010 that protocol number
is unassigned.  Anyone have any guesses what these things are?

Craig
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jul-87 09:27:01 EDT
From:      craig@NNSC.NSF.NET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Internet Protocol #77


    Here at the CSNET CIC we're collecting some statistics to help us
figure out why the CSNET relay is in the top-10 traffic list.

    One of the things we've done is to start tracking the protocol
field in each IP header (to show us which protocols are causing most
of our traffic).  And before I've even analyzed our data I've found a
small anomaly.

    It clearly isn't causing our traffic problems, but we're receiving
packets with the IP protocol field set to 77 decimal.  So far it is 21
packets in the past 16 hours).  According to RFC 1010 that protocol number
is unassigned.  Anyone have any guesses what these things are?

Craig

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jul 87 12:16:42 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA, ietf-interest@gateway.mitre.org, nsfnet@NNSC.NSF.NET
Subject:   calendar service

Hi Folks,

    The NSF Network Service Center is now maintaining an on-line calendar
of events of interest to the Internet/NSFNET community.  The hope is that
this will help us all manage our time a bit better :-).  I've appended the
calendar for August as an example below.

    Calendar entries are available by anonymous FTP from sh.cs.net
(calendar/<mon> where <mon> is the three letter abbreviation for the
month) or through the CSNET Info-Server (info@sh.cs.net) using a request
of the form:

request: calendar
topic: <mon>
request: end

Again, <mon> is the three letter abbreviation, or the full month name,
e.g. "aug" or "august".

    If you have meetings or conferences you would like included on this
list, mail to calendar-request@nnsc.nsf.net.

Thanks,

Craig

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

Request:  calendar
Topic:    august
Document Updated:  30 June 87
Subject:  Internet Calendar for August 

AUGUST 1987

Aug 3-6        Santa Clara, CA (ACE)   TCP/IP Tutorials (Internet, Unix,VMS)
                                       Open, for fee.
                                       Dan Lynch (Lynch@A.ISI.EDU)
                                       408-996-2042

Aug 4-7        Colo Springs, CO       *Symposium on Simulation of Computer
				       Networks
				       Contact: Mitchell Spiegel, GTE
				       1700 Research Blvd, Rockville, MD 20850
				       (301)294-8434

Aug 10-12      Vancouver, BC CANADA   *6th ACM SIGACT-SIGOPS Symposium on
				       Principles of Distributed Computing 
				       (PODC)
				       Contact: David Kirkpatrick, Dept. of 
				       Computer Science, U. of British Columbia
				       Vancouver, BC Canada V6T 1W5

Aug 10-15      Honolulu, Hawaii        2nd Int'l Conference on Human-Computer
				       Interaction
				       Contact:Gavriel Salvendy, School of
				       Industrial Engineering, Purdue
                                       University, W. Lafayette, IN 47097
				       (317)494-5426

Aug 11-14      Stowe, VT              *SIGCOMM Workshop
				       Sponsors:  ACM SIGCOMM
				       Contact:  Walter Kosinski
				       Box 4328, Greenwich, CT 06830
				       
Aug 17-21      University Pk, PA      *1987 Int'l Conference on Parallel Pro-
	       Penn State U	       cessing
				       Contact: 1987 International Conference
				       on Parallel Processing, E.E. East Bldg,
				       Penn State University, U. Park, PA 16802


Aug 31-Sep 2   Monterey, CA (ACE)      ISO Development Seminar
                                       Open, for fee.
                                       Dan Lynch (Lynch@A.ISI.EDU)





* Taken from "Communications of the ACM", June 1987, Volume 30, Number 6


-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jul-87 11:26:25 EDT
From:      woody@MACOM3.ARPA (robert a woodburn)
To:        comp.protocols.tcp-ip
Subject:   talking to sri-nic.arpa

Why can't I get through to sri-nic to get a host table update?
Did I miss something in the last month?  I can send and receive
mail just fine, but I cannot use ftp or even ping.  Could it be
our gateway?

Hello?  Toto I don't think we're in Vienna, VA anymore....

					wood y

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jul-87 11:52:00 EDT
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        comp.protocols.tcp-ip
Subject:   Re: Israel Tcp/Ip Plans


Henry,
          SMTP has, within its design, the capablility of
sending/receiving interactive messages which appear on the destination
addresses terminal.  Take a look at the <SEND> command in RFC 821.  I
realize that not many implementations may use this, but it is part of
the SMTP spec.  You might want to check it out.  It might be fairly
trivial to adapt the mailer to recognize that command, and to have a
user interface to send the message.

                    John G. Ata

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jul-87 13:25:32 EDT
From:      neerma@COD.NOSC.MIL.UUCP
To:        comp.protocols.tcp-ip
Subject:   TCP between IBM AT and SUN problem

We have several IBM ATs(and compatibles) on an Ethernet along
with SUN terminals .  We are developing network code on the
ATs to interface with Network Research's FUSION TCP package.
Basically the AT act as servers.  To test our servers we hav e
client programs on the SUNs.  The server ATs send data to the
Suns as fast as the TCP can accept it.  Since the client on the
SUN is relatively slow(scrolling data to SUN screen) TCP's
flow control mechanism is invoked.  The problem is that at
some point the AT will stop sending data for long periods of
time(on the order of minutes). Using a netmonitor program the
packet trace reveals the following phenomena: the SUN TCP
apparantly ACKs the same data 'bokoo' times; that is the trace
shows at some times the SUN is the only one generating packets
the packets are TCP only packets(no data) the ACK and SEQ #s
are the same on all the packets, the AT is sending nothing in
response, the SUN fills up a couple of screens with these,
the AT comes to a screeching halt.  The packets from the SUN
show a large window being advertised yet no data comes from the
AT.  After several minutes the AT seems to 'wake up' and start
sending again.  From the netmonitor viewpoint it looks as though
the SUN inundates the AT with ACKs; the AT gets uptight and
refuses to send any data for a while. 

It seems the SUN is misbehaving by ACKing data more than once.
Since the data field is 0 and only the ACK flag is on it seems
the only purose of these packets is to ACK data but maybe I'm
missing something. Maybe its trying(correctly) to open a window.
(If so, taking a RAMBO approach). The AT by the way has a 3COM
505 interface to the ethernet.

Another problem we have seen during this developement are 
what I would call silly windows being advertised by the SUN.
Do SUNs still suffer from this problem?  I thought this was
done away with long ago?

Merle Neer
NOSC

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

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jul-87 14:51:35 EDT
From:      haynes@ucscc.UCSC.EDU.ucsc.edu (99700000)
To:        comp.protocols.tcp-ip
Subject:   Re:  Wollongong TCP/IP for VAX/VMS

In article <8707081702.AA03732@topaz.rutgers.edu> ron@TOPAZ.RUTGERS.EDU (Ron Natalie) writes:
>Would you like to propose an alternative.  The other major

I've heard there is a new package from SRI, and there is also a package from
Tektronix that is something like free for big VAXen and not free for Microvaxen.Sorry, I don't have any further info.

Jim

haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Jul-87 15:01:27 EDT
From:      salzman@rdlvax.UUCP (Gumby)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Problems with internetwork routing in 4.2bsd


Does anyone know of any inherent problems/bugs in vanilla 4.2bsd
internetwork routing? Our machine has just been put on the ARPANET
via a 19.2K baud leased line to an imp off site (using an ACC HDH 
interface). We can't seem to connect to any site outside of the
ARPANET (i.e. any site that does not have an address of 10.?.?.?).
Every attempt times out. I realize there's the possibility of
the gateways being too loaded, but, I can get from another machine
that lies on another net (i.e. milnet) to our host without any
problems -- so it only effects outgoing attempts. Doing a netstat
shows that the state it's hung in is "SYN_SENT", and it seems to
never change that state. Doing a netstat -r shows that some attempt
has been made to connect on the gateway (there will be a number in
the "use" column for that gateway). 

Does anyone have any clue why this is happening? Are there any fixes
that can be obtained? This is a vanilla 4.2bsd system on a VAX 11/780.
We are planning an upgrade to 4.3bsd fairly soon, but not soon enough.
Any help would be greatly appreciated.... Thanks.
-- 
* Isaac Salzman - Systems Analyst/Admin.                      ----     
* Research Development Labs (RDL)                            /o o/  /  
* 5721 W. Slauson Ave., Culver City, CA. 90230               | v |  |  
* AT&T: +1 213 410 1244, x118                               _|   |_/   
* ARPA: salzman@rdlvax.RDL.COM                             / |   |
* UUCP: ...!{psivax,csun,sdcrdcf,ttidca}!rdlvax!salzman    | |   |     

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jul-87 03:23:20 EDT
From:      MKL@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: talking to sri-nic.arpa

I can't tell you why you couldn't get thru to the NIC for a host
table update.  I can tell you that on July 9th, 60 people did get
thru and retrieve a host table, despite some network related problems
we had.  If you can supply specific details of your problem
to ACTION@SRI-NIC.ARPA we will investigate.

Mark
-------

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jul-87 04:29:50 EDT
From:      craig@NNSC.NSF.NET.UUCP
To:        comp.protocols.tcp-ip
Subject:   calendar service


Hi Folks,

    The NSF Network Service Center is now maintaining an on-line calendar
of events of interest to the Internet/NSFNET community.  The hope is that
this will help us all manage our time a bit better :-).  I've appended the
calendar for August as an example below.

    Calendar entries are available by anonymous FTP from sh.cs.net
(calendar/<mon> where <mon> is the three letter abbreviation for the
month) or through the CSNET Info-Server (info@sh.cs.net) using a request
of the form:

request: calendar
topic: <mon>
request: end

Again, <mon> is the three letter abbreviation, or the full month name,
e.g. "aug" or "august".

    If you have meetings or conferences you would like included on this
list, mail to calendar-request@nnsc.nsf.net.

Thanks,

Craig

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

Request:  calendar
Topic:    august
Document Updated:  30 June 87
Subject:  Internet Calendar for August 

AUGUST 1987

Aug 3-6        Santa Clara, CA (ACE)   TCP/IP Tutorials (Internet, Unix,VMS)
                                       Open, for fee.
                                       Dan Lynch (Lynch@A.ISI.EDU)
                                       408-996-2042

Aug 4-7        Colo Springs, CO       *Symposium on Simulation of Computer
				       Networks
				       Contact: Mitchell Spiegel, GTE
				       1700 Research Blvd, Rockville, MD 20850
				       (301)294-8434

Aug 10-12      Vancouver, BC CANADA   *6th ACM SIGACT-SIGOPS Symposium on
				       Principles of Distributed Computing 
				       (PODC)
				       Contact: David Kirkpatrick, Dept. of 
				       Computer Science, U. of British Columbia
				       Vancouver, BC Canada V6T 1W5

Aug 10-15      Honolulu, Hawaii        2nd Int'l Conference on Human-Computer
				       Interaction
				       Contact:Gavriel Salvendy, School of
				       Industrial Engineering, Purdue
                                       University, W. Lafayette, IN 47097
				       (317)494-5426

Aug 11-14      Stowe, VT              *SIGCOMM Workshop
				       Sponsors:  ACM SIGCOMM
				       Contact:  Walter Kosinski
				       Box 4328, Greenwich, CT 06830
				       
Aug 17-21      University Pk, PA      *1987 Int'l Conference on Parallel Pro-
	       Penn State U	       cessing
				       Contact: 1987 International Conference
				       on Parallel Processing, E.E. East Bldg,
				       Penn State University, U. Park, PA 16802


Aug 31-Sep 2   Monterey, CA (ACE)      ISO Development Seminar
                                       Open, for fee.
                                       Dan Lynch (Lynch@A.ISI.EDU)





* Taken from "Communications of the ACM", June 1987, Volume 30, Number 6

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1987 10:45-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        jcollas@XN.LL.MIT.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SNAP Protocol
Without reading the document, I'd guess that SNAP stands for "Sub
Network Access Protocol".  and as such refers  to  not  one,  but
several  protocols  including  the  Etherenet, DDN X.25 and AHIP,
Hyperchannel, Proteon ring...  etc...

Mike
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jul-87 10:37:43 EDT
From:      gkn@SDS.SDSC.EDU
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for VMS

We used to run TWG's stuff here until I got tired of it crashing the VAXcluster
and flooding the local ethernet with garbage.

We've been using SRI's MultiNet-Plus for about a year now, and are quite
pleased with it.  It not only works, it works well.  You have your choice of
mail systems (Pony Express, PMDF, and Software Tools), an excellent TELNET
and FTP implementation, QIO compataibility with TWG's stuff, a name server,
dynamic routing (EGP, RIP, and Hello), nice tools to maintain the network
configuration and server database.  In addition to TCP/UDP, it supports Chaos
and PUP.

gkn
--------------------------------------
Arpa:	GKN@SDS.SDSC.EDU
Bitnet:	GKN@SDSC
Span:	SDSC::GKN (27.1)
USPS:	Gerard K. Newman
	San Diego Supercomputer Center
	P.O. Box 85608
	San Diego, CA 92138
AT&T:	619.534.5076

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jul-87 11:57:25 EDT
From:      stephen@blisierra.BLI.COM (Stephen Belair)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Seeking info on the AMD 7992A ("LANCE") Ethernet controller


Does anyone out there have any experience with the AMD Ethernet chip, or
with the Mostek 68590 LANCE Ethernet controller? Any nice features with 
either? Any nasty bugs? Performance? 

Any comments or experience with these are welcomed and would be greatly
appreciated.

stephen belair

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jul-87 12:24:37 EDT
From:      cracraft@ccicpg.UUCP (Stuart Cracraft)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Uselessness

In article <8707090344.aa02151@SEM.BRL.ARPA> dpk@BRL.ARPA (Doug Kingston) writes:
>Well, I am again trying to use the Internet to accomplish real
>work and finding it almost impossible due to the almost none-existent
>throughput.
>
There have been some real performance problems lately. Multi-second
delays between characters on TAC access from a TAC local to the area
code of the destination host.

>Lest some of you misunderstand, there are parts of the Internet
>that are reasonably healthy, such as the MILNET proper...
>But the MILNET is only a part of the much larger Internet.  
>The MILNET alone is of little use to us if we cannot talk 
>successfully to the rest of the Internet.
>
The situation described above occurred on a MILNET TAC.
Response from NIC and the host (a central hub) indicated
that it was a known problem that BBN is actively working on.
TAC performance has improved somewhat since then though
multi-second delays still occur, frequently.

>...
>Who do we have to push to get this fixed?
Talk with NIC and BBN.

    Stuart

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jul-87 12:39:00 EDT
From:      RCL@uokucs.UUCP ("Rich Lewis : Black Dragon")
To:        comp.protocols.tcp-ip
Subject:   User

I have been recieving messages addressed to JAY at this site, there does not
exists any such user. Enclosed is a copy of one such letter with the path.
Please make the necessary changes to you mailing list.

						Thanks for your consideration,
						Rich Lewis, Postmaster.
-------------------------------------------------------------------------------

> Received: from uokmax.uucp by uokucs.uucp; Thu, 9 Jul 87 02:39 CST
> Received: from texsun by uokmax.uucp id aa32127; 9 Jul 87 1:40 CDT
> Received: from snail.sun.com (snail-swanbb) by Central.Sun.COM (3.2/SMI-3.2)
> 	id AA02309; Wed, 8 Jul 87 23:22:19 CDT
> Received: from Sun.COM (arpa-dev) by snail.sun.com (4.0/SMI-3.2)
> 	id AA19753; Wed, 8 Jul 87 21:19:27 PDT
> Received: from devvax.TN.CORNELL.EDU by Sun.COM (4.0/SMI-3.2)
> 	id AA06233; Wed, 8 Jul 87 21:19:58 PDT
> Received: by devvax.TN.CORNELL.EDU (5.54/1.3-Cornell-Theory-Center)
> 	id AA06593; Thu, 9 Jul 87 00:22:10 EDT
> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 7 Jul 87 20:01:03-PDT
> Received: by ucbvax.Berkeley.EDU (5.58/1.27)
> 	id AA16474; Tue, 7 Jul 87 19:47:22 PDT
> Received: from USENET by ucbvax.Berkeley.EDU with netnews
> 	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
> 	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
> Date: 7 Jul 87 22:51:39 GMT
> From: Dennis Weaver <dennisw@iscuva.uucp>
> Organization: ISC Systems Corporation, Spokane, Wa.
> Subject: Request for info on public domain TCP-IP source
> Message-Id: <562@iscuva.ISCS.COM>
> Sender: tcp-ip-request@sri-nic.arpa
> To: tcp-ip%sri-nic.arpa@texsun.uucp
> 
> We are interested in locating "Public Domain" source of TCP-IP, FTP & TELNET
> written in "C" (if such a thing exists).  Does anyone know where we can find
> these sources  ???
> 
> Thanks in advance.

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

Richard C. Lewis, Jr.
University of Oklahoma
University Computing Services
601 Elm, PhSC 235
Norman, Ok 73019
USA

Voice:		(405) 325-6988

E-Mail in order of preference.

	USEnet:		rcl%uokucs@uokmax.uucp
			rcl@uokucs.uucp
			rich@uokmax.uucp
	UUCP:		uokucs!rcl
			uokmax!uokucs!rcl
			seismo!okstate!uokmax!uokucs!rcl
			ihnp4!gorgo!rcl
	Internet:	rcl@gorgo.att.com


			Pick a net, ANY net.

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jul-87 13:45:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: SNAP Protocol

Without reading the document, I'd guess that SNAP stands for "Sub
Network Access Protocol".  and as such refers  to  not  one,  but
several  protocols  including  the  Etherenet, DDN X.25 and AHIP,
Hyperchannel, Proteon ring...  etc...

Mike

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jul-87 13:49:42 EDT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: X.400 gateways to RFC822 mail systems


>The messages on EARN and Israeli conversion reminded me of an issue
>that's worth airing.  The early efforts to provide X.400 mail gateways
>are not very encouraging.  

Your message had 15 header lines on my screen, the X.400 example had 18;
it doesn't seem that big a difference.  I'm not a mail expert but I
suspect the header lines will necessary during trouble shooting.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Jul-87 14:31:31 EDT
From:      netser@limbo.UCI.EDU (Richard Johnson)
To:        comp.protocols.tcp-ip
Subject:   Strange ICMP messages

I was looking at ICMP packets on our network this morning and noticed
that we're getting LOTS (about 1 every 5 seconds!) of "time exceeded"
ICMP messages from ai-gw.ai.mit.edu (128.52.22.8) destined to icsd.uci.edu
(192.5.19.4).  The strange thing about this is that we don't have any
connections with any place at MIT!  I check icsd for current connections
and find there are only 4 and that all 4 are to other machines on our local
network!

Maybe this has something to do with the fact that the whole Internet seems
to be terribly bogged down these days?  Does anyone have an explanation?

----------------------------------------------------------------------------
Richard Johnson                          netser@ics.uci.edu       (Internet)
UCI ICS Network Services                 ...!ucbvax!ucivax!netser     (UUCP)

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11-Jul-87 03:34:27 EDT
From:      jac@UMD5.UMD.EDU (Joseph A. Cimmino Jr.)
To:        comp.protocols.tcp-ip
Subject:   Re: SNAP Protocol

It's been a long time since I've looked at the ULANA spec, but the
SNAP you're intersted in may be the "SubNetwork Access Protocol" that
is used to encapsulate IP/ARP on IEEE 802 LANS.  Snap is used on the
IBM Token Ring in the IBM implementation of PC/IP.

See RFC-990 "Assigned Numbers", page 36, section on IEEE numbers of
interest for a spec.  There may also be an RFC on SNAP itself and/or
a later issue of "Assigned Numbers".

Hope this is a helpful start.  /joe
------------------------------
Joseph A. Cimmino, Jr.    University of Maryland, Systems    jac@umd5.umd.edu
1+ 301 454 2946                   PC/IP Group              cimminoj@umdd.bitnet

Bertolt Brecht:  You made your bed, so you lie in it.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jul 87 14:06:15 PDT
From:      Bill Yundt <GD.WHY@forsythe.stanford.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin
REPLY TO 07/07/87 11:46 FROM KHANNA@AHWAHNEE.STANFORD.EDU "Raman Khanna": fyi

Mr. Crispin,

Wollongong's CURRENT release ....v 3.0....seems to work
quite well, contrary to your pathetically ill informed
view.  I suggest you look into your facts before ventilating
your hot air.

People who call you should be encouraged to move to the
correct version of the software ....which does appear to
have bugs fixed...in addition to supporting domains, etc.

The Wollongong Group got a deservedly bad reputation some
time back because they didn't put any inside effort in
to the product...relying on Dave Kashtan for everything.
They appear to have remedied that problem and become
independent of Mr. Kashtan's availability....both of
which are probably constructive.

Bill Yundt, Director, Networking and Communications Systems
Stanford University

To:  TCP-IP@SRI-NIC.ARPA
cc:  KHANNA@AWANEE
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11-Jul-87 13:19:41 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Israel Tcp/Ip Plans

Hank,  Thanks for posting your large document on Israel's plan for
adopting TCP/IP while waiting for the ISO protocols to get more fully
defined and supported.  It certainly shows a lot of thought and effort
has been made in arriving at this decision.  I noticed that you left
out a number of sections that deal with costing data in order to comply
with Bitnet and EARN strictures.  Since you sent this directly to the TCP/IP
list you could put them back in and make the description and analysis
much more complete.

Thanks,
Dan
-------

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1987 13:19:41 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Henry Nussbacher <HANK%BARILVM.BITNET@WISCVM.WISC.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re: Israel Tcp/Ip Plans
Hank,  Thanks for posting your large document on Israel's plan for
adopting TCP/IP while waiting for the ISO protocols to get more fully
defined and supported.  It certainly shows a lot of thought and effort
has been made in arriving at this decision.  I noticed that you left
out a number of sections that deal with costing data in order to comply
with Bitnet and EARN strictures.  Since you sent this directly to the TCP/IP
list you could put them back in and make the description and analysis
much more complete.

Thanks,
Dan
-------
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11-Jul-87 14:51:45 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  Wollongong TCP/IP for VAX/VMS

It appears that Wollongong's attitude may be changing.  After posting
my comments (which were not critical of Wollongong in any case, since
as we as I know, we had never reported this problem to them) I got
a call from one of their folks, with some suggestions for short-term
fixes, and assurances that the newest release (which we just got,
but have not yet installed) will provide more permanent solutions.
He was extremely helpful and knowledgeable.

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11-Jul-87 17:06:15 EDT
From:      GD.WHY@FORSYTHE.STANFORD.EDU (Bill Yundt)
To:        comp.protocols.tcp-ip
Subject:   fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin

REPLY TO 07/07/87 11:46 FROM KHANNA@AHWAHNEE.STANFORD.EDU "Raman Khanna": fyi

Mr. Crispin,

Wollongong's CURRENT release ....v 3.0....seems to work
quite well, contrary to your pathetically ill informed
view.  I suggest you look into your facts before ventilating
your hot air.

People who call you should be encouraged to move to the
correct version of the software ....which does appear to
have bugs fixed...in addition to supporting domains, etc.

The Wollongong Group got a deservedly bad reputation some
time back because they didn't put any inside effort in
to the product...relying on Dave Kashtan for everything.
They appear to have remedied that problem and become
independent of Mr. Kashtan's availability....both of
which are probably constructive.

Bill Yundt, Director, Networking and Communications Systems
Stanford University

To:  TCP-IP@SRI-NIC.ARPA
cc:  KHANNA@AWANEE

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Jul-87 02:07:52 EDT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Protocol #77

Protocol number 77 is Sun's ND (not to be confused with NFS, which uses
UDP).  None of these should ever appear on the Internet!  Someone is
leaking local traffic.

Chris

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Jul-87 03:37:11 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  talking to sri-nic.arpa

Woody,

The Wicked Witch of the East wasn't zapped by Dorothy's house after all.
She managed to axe some useful nets from the linkabit-gw tables, including
192.5.39 (us). The tables, after all, are too small. As for SRI-NIC, try
to connect to its ARPANET address 10.0.0.51 directly, rather than its
hosts.txt address, which is on MILNET.

Dave

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Jul-87 13:35:17 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Protocol #77

77 is Sun's network disk protocol.  This is the predecessor to NFS,
and will be phased out near the end of the year.  Apparently this
number was not assigned by the number Czar, but will simply pulled
out of a hat and used unofficially.

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Jul-87 17:34:54 EDT
From:      jeff@umbc3.UMD.EDU (Jeffrey Burgan)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for VAX/VMS

In article <12316245218.8.MRC@PANDA> MRC@PANDA.COM (Mark Crispin) writes:
>
>     I received my nth bug report from a Wollongong site today complaining
>that mail didn't work between them and a DEC-20.
>
>     The problem is, of course, that the Wollongong software simply does
>not work ... and that Wollongong simply does not care.

   We have been running Wollongong's software for 2 years and have 
never experienced any problems sending to a TOPS-20 machine.
This is not to say that mail always makes it through the first time,
but remember we are talking about the Internet. For a resolution to 
most problems, people should possibly look no further than
there own systems to make sure they have configured them correctly
and that nothing has "mysteriously" changed. Set-up changes do not
constitute a software bug. 
  
   All that you have accomplished with this article is to 
misrepresent the facts. If people are really reporting bugs to you,
would it not be more productive (both to you and us) to report
it so that if there is a bug, it can be fixed? If you call them
and tell them something is not working, they will at least work with
you to solve the problem. Simply, my Wollongong software DOES work.
 
   In the past 2 years, I have made my criticism of the software
known to them, bugs and all. Although not perfect, their
software and support have improved greatly over the last year, and 
they have worked with me through several bugs and/or software 
modifications. 
What would you have VMS user's use?

    

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Jul 87 21:53
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@Cs.Ucl.AC.UK>
To:        Doug Kingston <@Cs.Ucl.AC.UK:dpk@brl.arpa>
Cc:        ietf <@Cs.Ucl.AC.UK:ietf@gateway.mitre.org>, tcp-ip <@Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: Internet Uselessness
Doug,
 
I also have suffered (not quietly) for the last 10 months with the
terrible state of the Internet. I know some people in DARPA/BBN/DCA
but seemingly not the ones who "can make it happen" - (no offence
intended to those I know). More than the Internet getting a black eye
consider the following.
 
The Internet uses TCP/IP. There are elements of the Internet (Arpanet,
Milnet) that are under-resourced for the traffic - the performance can
be so bad that my remote host timeouts on me whem I'm trying to login.
TCP/IP is pushed by many members of DOD as the right protocol to be
used for networks in a military environment. Yes, they are going to
transition to ISO OSI - same protocols almost, TP4 and IP (via NBS).
 
Now my  vision of a military Internet is that it starts off in
peacetime with JUST enough resource for peacetime traffic (budget
problems on the Defence Vote we'll plug it next year etc (I think
you call it Get Well Later in the US)). Then the action starts to
warm up a little (the Gulf - Iraq/Iran) and the Internet falls over
the knee of the curve.
 
In part this is a consequence of some very stupid implementations of
TCP/IP, some elements of the protocol which if implemented in
a straightforward way cause congestion once it has occured, and
seemingly a complete failure to develop some other concepts (access
control sensitive to traffic volume, precedence and priority) to the
same degree. While the PTT X25 solution does potentially have its
problems in a hostile environment (note - X25 is more an interface than
an end-to-end protocol and the spec does not forbid self-healing nets
being built - it just needs the market to pay for it) its performance
is generally to a high standard. For good reason, revenue depends on
connection time AND traffic volume.
 
Maybe the answer is to fund the Internet a different way - the PTT
way.
 
John
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jul-87 00:53:00 EDT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Uselessness

Doug,
 
I also have suffered (not quietly) for the last 10 months with the
terrible state of the Internet. I know some people in DARPA/BBN/DCA
but seemingly not the ones who "can make it happen" - (no offence
intended to those I know). More than the Internet getting a black eye
consider the following.
 
The Internet uses TCP/IP. There are elements of the Internet (Arpanet,
Milnet) that are under-resourced for the traffic - the performance can
be so bad that my remote host timeouts on me whem I'm trying to login.
TCP/IP is pushed by many members of DOD as the right protocol to be
used for networks in a military environment. Yes, they are going to
transition to ISO OSI - same protocols almost, TP4 and IP (via NBS).
 
Now my  vision of a military Internet is that it starts off in
peacetime with JUST enough resource for peacetime traffic (budget
problems on the Defence Vote we'll plug it next year etc (I think
you call it Get Well Later in the US)). Then the action starts to
warm up a little (the Gulf - Iraq/Iran) and the Internet falls over
the knee of the curve.
 
In part this is a consequence of some very stupid implementations of
TCP/IP, some elements of the protocol which if implemented in
a straightforward way cause congestion once it has occured, and
seemingly a complete failure to develop some other concepts (access
control sensitive to traffic volume, precedence and priority) to the
same degree. While the PTT X25 solution does potentially have its
problems in a hostile environment (note - X25 is more an interface than
an end-to-end protocol and the spec does not forbid self-healing nets
being built - it just needs the market to pay for it) its performance
is generally to a high standard. For good reason, revenue depends on
connection time AND traffic volume.
 
Maybe the answer is to fund the Internet a different way - the PTT
way.
 
John

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jul-87 07:55:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet meltdowns

Charles,

In case I haven't said it earlier, I just want you to know that your
concrete contributions to the Internet technology and practical comments
on various pieces of software and hardware have been extremely helpful.

Keep up the good work (fight the good fight?).

Vint Cerf

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jul-87 10:58:27 EDT
From:      weltyc@NIC.NYSER.NET (Christopher A. Welty)
To:        comp.protocols.tcp-ip
Subject:   fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin



> Wollongong's CURRENT release ....v 3.0....seems to work quite well,
> contrary to your pathetically ill informed view.  I suggest you look
> into your facts before ventilating your hot air.

	Unnecessary, quite unnecessary.

	One of the problems we've been having is the fact that the TWG
software for VMS and UNIX V doesn't support subnetting.  Is this fixed
with the new release?  Is there a new releasee of the System V stuff?
We are using version 1.1 (which is what ATT distributes).  I don't
remember what release we're running for the VMS machines...

---

Christopher Welty - Asst. Director, RPI CS Labs
weltyc@cs.rpi.edu       ...!seismo!rpics!weltyc

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jul-87 13:11:50 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Protocol #77

Chris,

Is "protocol number 77" expressed in octal or decimal? Protocol number 63
(decimal) or 77 (octal) is reserved for local use, according to the assigned-
numbers list. My interpretation of this is that gateways should not forward
IPgrams carrying this number, so the NSFNET Backbone gateways, at least, do
not; therefore, your traffic certianly did not rumble that way.

Having said this, I am somewhat concerned about loopback and other things
intended to have only local relevance and "never escape the local net." Some
things, in particular local routing information and local broadcasts seem
in tune with this notion, since they depend on addressing independent of
local-network characteristics. However, some others (ND, NFS?) depend on
the characteristics of the local net (delay, discard rate, etc.) as an intrinsic
requirement for acceptable service. The use of addressing scope to delimit
service range in such cases seems conuterproductive. What you really want is
scope determined by maximum acceptable delay; in other words, some mapping of
type-of-service plus maybe a new IP option. This is the same thing needed for
packet speech and, in fact, implemented in those gateways supporting the
Stream (ST) Protocol.

Dave

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jul 87 15:41
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@Cs.Ucl.AC.UK>
To:        Bill Yundt <@Cs.Ucl.AC.UK:GD.WHY@forsythe.stanford.edu>
Cc:        tcp-ip <@Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin
Bill,
 
I was delighted to hear your good news on Wollongong's TCP/IP implementation.
The current version in the UK does have the bad habit of sending single byte
TCP packets from Telnet - not being very kind to the current congestion
of parts of the Internet. We have found no way to make it send multi-byte. Does
the new version solve this?
 
Do Wollongong US see the TCP-IP discussion? If they do, I would appreciate
the UK supplier GEC Software getting the new version quickly.
I think our current version is 2.3.
 
John
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jul-87 18:41:00 EDT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin

Bill,
 
I was delighted to hear your good news on Wollongong's TCP/IP implementation.
The current version in the UK does have the bad habit of sending single byte
TCP packets from Telnet - not being very kind to the current congestion
of parts of the Internet. We have found no way to make it send multi-byte. Does
the new version solve this?
 
Do Wollongong US see the TCP-IP discussion? If they do, I would appreciate
the UK supplier GEC Software getting the new version quickly.
I think our current version is 2.3.
 
John

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jul-87 20:33:26 EDT
From:      marcg@phred.UUCP (Marc Greisen)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Vaxes and the System 38



Summary:  We have several vaxes that run either VMS and Ultrix and talk on
	  ethernet.  We want to talk to two IBM system 38's that 
	  talk together on a X.25 network.

At present our vaxes talk on ethernet.  What we need is to talk to 
the system 38 with something other then sneaker net.  What we want 
is a tcp/ip implementation for the system 38, with ftp,telnet,smtp,ect...

Solutions we have looked at:

1. Dec SNA gateway software/hardware
	Our Dec sales person has told us the current
	implementation of SNA on the 38 will not support a
	connection to dec's gateway.

2. Kodaks Syncra software/hardware
	We have only looked at the manuals but it seems that
	they implement a black box solution.  Their software will
	transfer files and provide terminal emulation, but only with
	menu driven utilities, no hooks into the software to
	build our own applications.  They run tcp/ip on the LAN
	but you can't do anything with it.


Possibilities:

1. The system 38's run some kind of X.25 network.  I don't know
	anything about x.25, is there some equivalent to ftp,smtp
	ect...?  I do know there are boxes made that do ethernet
	to x.25 bridging.

2. Unknown vendor of tcp/ip for the 38

3. Hyper-channel?

It seems thought that there are no real flexible solutions. 
Any suggestions I could get that would provide possibilities or
solutions would be gratefully accepted.


			Marc Greisen
			Physio-Control Corp.
			...tikal!phred!marcg
			(206)867-4535

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Jul-87 21:21:28 EDT
From:      peter@julian.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for VAX/VMS

In article <8707071930.AA08177@nic.nyser.net> weltyc@NIC.NYSER.NET (Christopher A. Welty) writes:
>
>	You might also tell DEC about it, since they sell TWG software
>for VMS as the official VAX?VMS TCP/IP product.

In my last conversation with Digital about this, they said that Digital
had had  so much support trouble with The Wollongong Group that they were now
recommending the Fusion product for TCP/IP under VMS.
   I suppose that this might be just a Canadian phenomenon.

-- 
Peter Marshall, CCS, U. of Western Ontario, London, Canada N6A 5B7
(519)661-2151x6032 
pm@uwovax.BITNET; pm@uwovax.uwo.cdn; pm@julian.uucp; ...!watmath!julian!peter

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 00:25:58 EDT
From:      garrett@udel.EDU (Joel Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for VAX/VMS


We have been running WIN/TCP v3.0 for about a week now and have had few
problems beyond the initial installation.  The new release supports domains
and name-servers and fixes a LOT of problems with the old 2.x releases.
Their documentation and installation procedures have improved drastically
from their earlier releases.  There are still a lot of things you can't do
without their companion product, Eunice, but the documentation has changed
from just copies of man pages to very detailed installation, operation, and
programming notes  We used to have a lot of system crashes that seemed to
be related to the telnet daemon, but since we have upgraded there haven't
been any crashes.  Hopefully the system won't prove me wrong now, but so
far, I'm pretty pleased with the installation.

						Joel J. Garrett
						Research Associate
						University of Delaware
						Center for Composite Materials
						arpa address: garrett@udel-ccm.arpa

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 00:30:22 EDT
From:      garrett@udel.EDU (Joel Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for VMS


I've been hearing a lot of talk about a VMS implementation of TCP/IP
from either Tektronix or SRI.  Who can I get in contact with for more
information about this product?

					Joel Garrett
					University of Delaware
					Center for Composite Materials
					arpa address: garrett@udel-ccm.arpa

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 00:39:37 EDT
From:      garrett@udel.EDU (Joel Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin

> 	One of the problems we've been having is the fact that the TWG
> software for VMS and UNIX V doesn't support subnetting.  Is this fixed
> with the new release?

According to the docs for the VMS version, yes subnetting is supported now.

I wouldn't know about whether they have a new version of their AT&T stuff
out, but I'd imagine that they would.  On this same line, if any of you
who use the sysv wollongong stuff could drop me a line and give me some of
your impressions of this product, I would really appreciate it.  We have
several 3bs that were donated to our department by at&t and they are basically
sitting idle now as they can't talk to our other tcp/ip hosts.  If I get
enough of a response I'll summarize to the net.

					Thanks,
					Joel Garrett
					UofD, CCM
					arpa: garrett@udel-ccm.arpa

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 01:36:21 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet meltdowns

Charles,  I just had a chance to digest your "meltdown" note.  I have
seen no response on the net suggesing any cures for your ailments.
Nor do I expect any...  You describe the "state of the art".  

Ane they say there is little need for testing of TCP/IP!!!

I am extremely curious if the testing planning that is going on
at COS for the ISO stack(s) is looking at the kind of grief
that you are currently experiencing?  ON the other hand don't
most of your problems come from multiple interpretations of
the "broadcast" address?

Dan
-------

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1987 01:36:21 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re: Ethernet meltdowns
Charles,  I just had a chance to digest your "meltdown" note.  I have
seen no response on the net suggesing any cures for your ailments.
Nor do I expect any...  You describe the "state of the art".  

Ane they say there is little need for testing of TCP/IP!!!

I am extremely curious if the testing planning that is going on
at COS for the ISO stack(s) is looking at the kind of grief
that you are currently experiencing?  ON the other hand don't
most of your problems come from multiple interpretations of
the "broadcast" address?

Dan
-------
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 03:33:45 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet meltdowns

Well, I know the cure for broadcast storms, and I think plenty of
other people do as well.  I mostly give it in the message.  You simply
have to be very careful to do validity checking before forwarding
packets or generating ICMP error messages.  As far as I can tell, 4.3
is fairly good, so it's mostly a matter of waiting for vendors to
catch up to 4.3.  All the Unix vendors we deal with have either just
released 4.3-based network code or are about to do so.  I agree with
your implication that validation of TCP/IP implementations would be
useful.  I understand that it is hard to design a test setup that will
make sure a TCP follows all the best performance guidelines.  But it
is not at all hard to make sure that an IP is designed so it won't
contribute to broadcast storms.  

My first inclination is to say that it will be easy for ISO to avoid
this problem.  It isn't hard to come up with a set of implementation
guidelines that avoid broadcast storms.  What really triggered this
was the Internet changing its idea of the broadcast address.  I mean,
it shouldn't have been hard to forsee this problem when 0 was changed
to -1.  (On the other hand, subnetting probably required enough of a
change that things would have broken anyway, so there might have been no
way to avoid problems.)

However this may be giving too much credit to people.  The people who
will be implementing ISO are exactly the same people who have ignored
the TCP/IP implementation guidelines.  If people can do IP's that
don't respond to ICMP echo, presumably they can find ways to mess up
ISO as well.  It seems to me that ISO's equivalent of the broadcast
address change is going to be the incredibly complex address
structure.  It seems likely that few people will implement every
possible address format.  (Indeed probably they couldn't if they
wanted to.)  My intuition says that when different implementations
implement different sets of address formats, there are bound to be
some interesting interactions somewhere.  And with the worldwide PTT
network built into the addressing structure, I'll bet at some point
we'll manage to see some sort of storm that involves several
continentne 

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 04:00:00 EDT
From:      WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Wollongong TCP/IP for VAX/VMS


     I have a somewhat different viewpoint and solution to the ongoing
commentary concerning the Wollongong implementations of TCP/IP and
supporting software for various operating systems.
     First, let me point out that I get a different set of complaints
than Mark gets.  As the postmaster for this DEC-20 site, which is the
origin/relay point for several large mailing lists, I get a certain
set of complaints from the postmasters at BITNET sites who are having
problems with our headers.  What has made the difference is that in
most cases, I have been able to deal directly with the authors of the
software in question to resolve the problems in interpretation of the
RFCs using our real-world (Internet) messages.
     What is different with dealing with users of Wollongong software
is that they are in the position of having to report problems into a
corporate environment which has never had to interface their software
into a large heterogenous network such as ours.  In house, they test
their software against other implementations of their own software,
and it's kinda hard to duplicate a problem, much less be aware that a
problem exists in that situation.  Recall the early days surrounding
the rapid implementation and heterogeneous testing of various TCP/IP
implementations just a few short years ago and you'll understand my
point.
     The solution is obvious: The Wollongong Group should have a host
on the Internet so that they can find and fix problems before their
customers do, among other things.  This is not without precedent.  Not
too long ago, when the predominant operating system on the net was
TOPS20, DEC had, and still has one or more of their own TOPS20 hosts
on the net, testing their TCP/IP implementations (as was BBN testing
their versions).  I'm sure there are other examples, and I would
suppose that there were and still are other reasons for DEC to be on
the net.
     In a recent analysis I made of the various operating systems
listed in the NIC HOSTS.TXT file, by far the most predominant was
Unix, in various flavors on various machines.  Those hosts are mostly
running the 4.xbsd version, with Berkeley certainly represented
directly on the net.  The second was VMS systems, presumeably with a
majority of them running Wollongong software.
     Well, it appears such a Wollongong host does exist, according to
the NIC HOSTS.TXT file and the WHOIS database: TWG.ARPA, 26.5.0.73.
However, it appears to be non-operational or a reserved designation.
At least I have not been able to get a response from that host, yet.
     I firmly believe that the sooner they get on the net as an
operational host, we will see a significant and radical improvement in
the situation.  Anything that can be done to speed up their connection
would be of great benefit to all of us.
     Note carefully: I'm not necessarily advocating that only by
virtue of having a TCP/IP software package should every developer have
a host on the Internet.  Such developers should at least adopt a host
for in resident beta tests.  I suspect that every major developer
already has such a connection, except Wollongong...

--Frank

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 10:30:57 EDT
From:      stever@videovax.Tek.COM (Steven E. Rice, P.E.)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for VMS

In article <353@louie.udel.EDU>, Joel Garrett (garrett@udel.EDU) writes:

> I've been hearing a lot of talk about a VMS implementation of TCP/IP
> from either Tektronix or SRI.  Who can I get in contact with for more
> information about this product?

Some time back, I was asked this question by mail.  After a bit of
calling around inside Tektronix, I wound up talking to The Right Person.
The answer (for the Tektronix software) is, "Call your local Tektronix
field office."  (I don't know the answer for SRI.)

					Steve Rice

-----------------------------------------------------------------------------
new: stever@videovax.tv.Tek.com
old: {decvax | hplabs | ihnp4 | uw-beaver | cae780}!tektronix!videovax!stever

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 10:53:52 EDT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Routers and Internet Protocol #77

I've never seen any specification that requires IP routers to examine
the Protocol field in an IP datagram being forwarded.  I would argue
that it is improper for a IP router to do so.  This prevents
consenting users of the internet to use an experimental Protocol
across the Internet since some "router czar" has forbidden this
protocol.  My idea of IP, and IP routers, is that it should be
completely blind to what protocol is in use above it (with the
exception of ICMP).  This is the spirit of layering.

Another reason not to do this is that it's just *another* field to
have to check in the main forwarding loop of a router.  If everyone
solves all of the Internet's "control" problems in routers "with just
one little check" here or there, we'll never get the sort of
performance out of routers that the Internet community seems to want.
We have to keep forwarding packets as *simple* as possible, or we'll
have 68030 routers running at 50 (exaggeration) packets/second.

(Obviously, these are my opinions, not Proteon's...)

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 12:11:41 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin

The Wollongong VMS code we are running now, which is not the 4.3 stuff,
supports subnets and setting the broadcast address.

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 87 14:03:00 EST
From:      "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        enger
Subject:   WOLLONGONG TCP/IP for VMS
A number of individuals have criticized Wollongong for having many bugs and
shortcomings in their TCP/IP for VMS product.  Other individuals provide
testimonials about how Wollongong provided help, once informed of the problem. 

I found out that Wollongong has been trying to get connected to the Internet
for some time.  They wish to improve their service by being able to provide 
help across the net (as SUN Microsystems, and other responsible vendors do).

It has been said that a number of government sites are in need of help with 
their Wollongong TCP/IP software.  Would it not make sense to contact the 
network administrators and request some expediting of Wollongong's Internet 
connection?

Bob Enger
------
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 14:44:16 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Routers and Internet Protocol #77

John,

My remarks were confined strictly to the local-use issue and only when
the firewall is necessary. It turns out that the fuzzballs use IP protocol
63 (decimal) for routing purposes, so they have to check that field anyway.
Should it be advisable, I have no problem with this overhead in the general
case. It is surely no more intrusive than the address checking suggested
for generic IP gateways on this list and in recent RFCs.

Dave

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 15:03:00 EDT
From:      enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER")
To:        comp.protocols.tcp-ip
Subject:   WOLLONGONG TCP/IP for VMS

A number of individuals have criticized Wollongong for having many bugs and
shortcomings in their TCP/IP for VMS product.  Other individuals provide
testimonials about how Wollongong provided help, once informed of the problem. 

I found out that Wollongong has been trying to get connected to the Internet
for some time.  They wish to improve their service by being able to provide 
help across the net (as SUN Microsystems, and other responsible vendors do).

It has been said that a number of government sites are in need of help with 
their Wollongong TCP/IP software.  Would it not make sense to contact the 
network administrators and request some expediting of Wollongong's Internet 
connection?

Bob Enger
------

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 15:24:52 EDT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Problems with internetwork routing in 4.2bsd

It's not a bug.  You must make routing table entries for nets other than
net 10.  You do this by using the "route" command (in /etc or /usr/etc
depending on where you got your software from).  The easiest thing to
do is to set a default route to point to one of the ARPANET-MILNET
gateways, they will send you back an ICMP redirect to set the route
to the correct gateway if they are not it.  The gateways to use for
this are available from SRI-NIC.ARPA in the file 
    <NETINFO>ARPA-MAILBRIDGE-HOMINGS.TXT
Since rdl appears to be on IMP22, use the gateways

    MILNET-GW.ISI.EDU         SRI-MILNET-GW.ARPA
    10.2.0.22			10.4.0.51

You set this up by saying

	route add 0 10.2.0.22 1

-Ron

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 20:09:54 EDT
From:      dupuy@amsterdam.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet meltdowns

We once had a similar problem with a broadcast storm started by a diskless
Sun-3 trying to boot without a server.  Although you are correct when you say
that the boot broadcast address is hardwired in the Sun-3 PROMs, there is a
workaround, at least if you aren't on a class A or B network with subnets
(which is the case here at Columbia, and probably at Rutgers, *sigh*).

When a Sun 3 (diskless or otherwise) tries to boot, it looks in the EEPROM on
the CPU board for a default boot device.  If none is found, it takes the first
bootable device it finds, in the order it looks for them: disk, tape, ethernet.

A device spec looks something like this: ty(#,#,#), where ty is the board type
and the three numbers are the controller #, unit #, and partition #.  The
defaults for these are all 0.  In the case of an ethernet device, the unit # is
actually the last component of an internet host number, with 0 signifying the
broadcast address (which is all ones, not zeros).

When a fresh-from-the-factory diskless Sun-3 boots, the PROM, not finding
anything better than an ethernet device to boot from, starts a TFTP boot from
the device ie(0,0,0) or le(0,0,0), which can result in network meltdown if no
server responds (and sometimes even when one does).

However, if the server is at address 128.59.0.110 (say) you can set the default
boot device to be ie(0,110,0), and the only broadcasts which the booting sun
will generate will be the initial RARP and ARP requests that can be answered by
any machine, not just the server.

The catch in this is that if the server is at address 128.59.16.110, the host
part of the address (by the pre-subnetting rules, anyhow) is the number 4206,
and the largest possible unit number is 255.  One hopes that Sun will someday
support subnets in the boot PROM, so that this is no longer a problem; in the
meantime, one might consider using subnet 0 (if that's legal) for Sun diskless
clients and servers.

@alex
---
arpanet: dupuy@columbia.edu
uucp:	...!seismo!columbia!dupuy

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 20:14:00 EDT
From:      pml@casetek.casetek.UUCP (Pat Lashley)
To:        comp.protocols.tcp-ip
Subject:   PD TCP/IP requests

In the past couple of weeks, I have seen several requests for Public Domain
TCP/IP implementations; and no responses (presumably e-mailed to requestor ?).
This has led me to wonder if there is any such beast.

Anyone out there with information about ANY public domain or freely
redistributable TCP/IP implementation for ANY hardware/operating system
configuration, please e-mail me what information you have, and I will
post a summary (or statement of lack of response... :-).


Thanks,
-Pat

P.S.  This is not _just_ idle curiosity.  I think that the only way that I
can convince our managment to install TCP/IP on our VMS VAXen or PCs is to
find a way to reduce the cost per host to something that I could afford out
of my own pocket.

-- 
Internet:	casetek!patl@sun.com		PM Lashley
uucp:		...sun!casetek!patl		CASE Technology, Inc.
arpa:		casetek@crvax.sri.com		Mountain View, CA 94087
>> Anyone can have the facts; having an opinion is an art. <<

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 87 16:30:07 GMT
From:      ihnp4!alberta!auvax!louis@ucbvax.Berkeley.EDU  (Louis Schmittroth)
To:        tcp-ip@sri-nic.arpa
Subject:   PC UNIX wide area networking

We are starting to plan for wide-area networking of PCs with our
central UNIX machines.  The PCs will be spread out across the Province
of Alberta with dial-in access and/or Datapac (X.25) access to the
central machines.  At the central site we now have Berkeley UNIX on
VAXEN and SUNs connected by Ethernet, but we will also be considering
3B2s.  The PCs will be used by students to run CAI courseware on MS/DOS
but with administration and tutorial services from the central UNIX
systems.  Some CAI will also be delivered directly from the UNIX
systems.  We will be starting with 1200 and 2400 baud lines. The
PCs will be standalone workstations with only a modicum of computer
skills assumed for a typical student.  

What experience has anyone had using TCP-IP on PCs for wide-area
networking?

Where can we get information on SLIP?

Any other suggestions?

Please e-mail me and if there is enough response I will summarize.
-- 

Louis Schmittroth		           My employer has no opinions.
Computer Science
Athabasca University   ...{ubc-vision, ihnp4}!alberta!auvax!louis
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jul-87 21:35:47 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Protocol #77

You indicate that there is a maximum acceptable delay for NFS.  That's
not quite the case.  NFS does not adjust its timeouts and
retransmission times dynamically on a per-connection basis as TCP
does.  However you can set the constants as options in the mount.  It
should be possible to use NFS over connections with a long delay, as
long as the system administrator is able to choose reasonable values.
(A connection where values changed a lot would be a problem, of
course.)  This is obviously not the best way to design a protocol.  On
the other hand, they needed higher speed than is typical with TCP.
The evidence from this mailing list is that the commonly-used
techniques for choosing retransmission times and the like do not
always lead to the best results.  So I can understand a pragmatic
decision to optimize for local Ethernets and let the administrator
tune it for other connections.

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 02:24:32 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Protocol #77

Charles,

Well, we might both be on a spinnaker run. In fact, pals of mine
have mounted NFS over some interesting creeks in the NSF swamps,
so what are we tacking about? I think the pertinent points have
been butted and rebutted and thus would like to rest the case.
We still need a type-of-service architecture independent of addressing
and protocol specifications.

Dave

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 05:35:51 EDT
From:      iad@cs.hw.ac.uk (Iain A Donaldson)
To:        comp.protocols.tcp-ip,comp.os.vms,comp.sys.dec
Subject:   TEKTCP request


Does your site use the public domain tcp/ip software implemented for
VMS which originated with Tektronix (or the CMU enhanced version) ?.

If so I would be pleased to hear your comments as we are in the process of
requesting a user licence from Tek.  Also, if your site subscribes to
the TEKTCP mailing list, perhaps you could forward mail items to us in
the interval while we join the mailing list.
If you can help with the mailing list, please e-mail first and I will select 
a feed with the shortest path.

Some day we will give the DEQNA Ethernet board 
inside our microVAX some work to do !
-------------
-Iain Donaldson			JANET:	iad@uk.ac.hw.cs
 Heriot-Watt University		ARPA:	iad@cs.hw.ac.uk
 Dept of C.S.			UUCP:	..!ukc!cs.hw.ac.uk!iad
 Edinburgh, Scotland.

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 09:56:06 EDT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re:  fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin

Christopher,

We have been using TWG on our VMS VAXs in a subnetted environment without 
problems major problems for almost two years.  In fact, for about 6 months, 
we used a VAX8600 running VMS4.2 and TWG to drive two ethernets and 4 T1 lines,
until we switched to ULTRIX, ( I was not in favor of using a VAX/VMS as an
ip gateway but at that time we had no choice ).


					-- Sergio


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

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 10:40:36 EDT
From:      weltyc@NIC.NYSER.NET (Christopher A. Welty)
To:        comp.protocols.tcp-ip
Subject:   fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin


	Thanks.  I have forwarded your message to our VMS system
manager, who had claimed that subnetting in VMS was impossible.
However I still have the problem of doing subnetting with the TWG
software for SYS V on 3B2's....any clues?

---

Christopher Welty - Asst. Director, RPI CS Labs
weltyc@cs.rpi.edu       ...!seismo!rpics!weltyc

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Wed 15 Jul 87 14:29:45-PDT
From:      JERRY@STAR.STANFORD.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   RE: Wollongong TCP/IP for VAX/VMS
This is Dave Crocker, not Jerry Scott.  I recently joined The
Wollongong Group as Vice President, Software Engineering.  We will
soon be a host on MilNet, so I have not established an interim
mailbox elsewhere.  Please direct any short-term mail to me via
Jerry at this address.

The recent flurry of messages about Wollongong requires a formal
response.  As you are aware, The Wollongong Group has been
selling TCP/IP-based products for some years.  While we have been
successful in doing so, we have been less successful in maintaining
an unblemished reputation within the Internet community.  Recently,
we began taking actions to improve user perceptions.  From a technical
standpoint, the most significant of these actions involves upgrades
to our VAX/VMS product called WIN/TCP, especially converting to the
use of 4.3BSD as a code base for the TCP/IP implementation.  By doing
so, many long-standing problems were solved and performance has been
substantially improved.

On reviewing the messages that were sent to this distribution list,
it appears that the basis for two of the three explicitly critical
notes was a) system administration errors, and b) the use of very
old software.

At the present time, the new release (3.0) does not have any major
TCP/IP bugs known to us, nor does it crash the operating system.  The
immediately previous version (2.3) has not had any bugs that crash
VAXes for a time longer that any Wollongong personnel can remember.

It is our policy to work closely with all users of our products to
satisfy their needs.  Mark Crispin's July 6 email message, while it
contained no specific details, has been partially addressed in a
public reply citing cockpit error, rather than faulty software.  The
message was sent by a system administrator whose contact with Mark
triggered Mark's note.  The system administrator cockpit error we
identified does not involve any software bugs, but it does result in
setting the hosts's own name to a constant ("Unknown").  To eliminate
this confusion, we are changing the software to simply use the text
version of the IP address, whenever a similar administrator error is
made.

As part of a test against one of the systems running Mark's TCP, we
did encounter a client SMTP bug.  WIN/TCP 3.1, which will be
released shortly, fixes it.  It was only discovered because of high
delay in the Arpanet, thereby causing an extraordinary timeout.

In addition to providing technically competent software, Wollongong must
provide support for our products.  This is critical.  Although admittedly
flawed in the past, this, too, is being significantly improved, as the
recent TCP/IP activity cited above demonstrates.  "Support" is a
separate product and has to be purchased.  There have been some customers
who purchased the TCP product but did not, for whatever reason, purchase
support.  They then passed on the product to the real end-users and
claimed, falsely, that we would not provide support.  The cited case of
our software crashing a VAX cluster appears to be an example of this.
Although we subsequently established direct contact with a portion of
the actual end-users affected in this way, we were unfortunately unable
to find the remainder.

The suggestion about our connecting the the Internet is extremely well-
taken.  Part of the reason I was asked to join Wollongong was to bring
some Internet experience in-house.  The wheels were already in motion,
I discovered, to get a connection when I came on-board.  We were
supposed to be on MilNet about 4 months ago, and are in the final
stages of debugging the telecom link.

Lastly, with regard to our AT&T version of TCP/IP...it should be noted
that we developed this product at the specification of AT&T and we are
not free to add features on our own (AT&T markets the product; we
do not).  Hence, please ask them to suggest to us any changes that you
deem appropriate.

Dave
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 11:41:40 EDT
From:      kelly@root.co.uk (Kelly Dunlop)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   PCP/IP package for IBM PCs


I have a vague recollection of a mention on the net
of a TCP/IP package for IBM PCs called PCP/IP.
I think it comes from MIT and is possibly public domain.
Any information about how I can get hold of this,
or information from anyone who has used this will be gratefully
received. Please mail replies and if there is sufficient
interest I will post a summary to the net.

Thanks in advance,

Kelly


=====
Kelly Dunlop, Root Technical Systems, 3 Hayne Street, London, EC1A 9HH.
<kelly@root.co.uk>
Phone:  +44 1 606 7799   Fax:  +44 1 726 8158   Telex:  885995 ROOT G

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 12:36:01 EDT
From:      ccruss@ucdavis.UUCP (Russ Hobby)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   Re: PC UNIX wide area networking

SLIP connections seem to be a hot topic this summer so I thought I would 
post  a description of a summer  project we have at UC  Davis. SLIP is a 
cheap  and easy method to  get a computer connected  to a network and is 
particularly  good for microcomputers  since additional hardware  is not 
required. 

SLIP  is lacking in a few areas however. Throughput on slow serial lines 
(1200/2400  baud) can be  quite bad because  of the minimum  packet size 
(all  those  header  fields).  Also  there  is  no  standard  method  of 
establishing a SLIP connection for temporary network hookups. 

Our  project  addresses  the  first  problem  by using an abbreviated IP 
packet  on the SLIP line  and have the SLIP  gateway build legal packets 
before sending them onto the network. Likewise, incoming packets will be 
reduced  before sending them down  the SLIP line. Many  of the fields in 
the  IP packet header are either static  or unnecessary, IF you consider 
the host at the end of the SLIP is a leaf on the network and will not be 
routing.  Static fields are established at  login. Our current plans are 
for  four or eight  byte headers, depending  if the to/from  address has 
changed from the last packet. 

To  solve the second problem, we are creating a standard logon procedure 
that  will make  the connection  and set  the static  fields. We plan to 
support  connections via campus serial connection  (up to 19.2k) as well 
as  via dialup modems (300/1200/2400 baud, although I can not imagine it 
working well at 300!). 

We  doing the development with an IBM PC clone on one end and a VAX with 
4.3bsd  on  the  other.  We  have  started  with  some  of the MIT PC/IP 
derivations  on the PC side,  so that if the  project works out, it will 
usable  by others using the same software.  If there is interest, I will 
post information on how well it works. 

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

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 15:57:00 EDT
From:      heisterb@uiucuxe.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for VAX/VMS


/* Written  1:51 pm  Jul  9, 1987 by haynes@ucscc.UCSC.EDU.ucsc.edu in uiucuxe:comp.protocols.tcp-ip */
In article <8707081702.AA03732@topaz.rutgers.edu> ron@TOPAZ.RUTGERS.EDU (Ron Natalie) writes:
>Would you like to propose an alternative.  The other major

I've heard there is a new package from SRI, and there is also a package from
Tektronix that is something like free for big VAXen and not free for Microvaxen.Sorry, I don't have any further info.

Jim

haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes
/* End of text from uiucuxe:comp.protocols.tcp-ip */

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 17:29:45 EDT
From:      JERRY@STAR.STANFORD.EDU
To:        comp.protocols.tcp-ip
Subject:   RE: Wollongong TCP/IP for VAX/VMS

This is Dave Crocker, not Jerry Scott.  I recently joined The
Wollongong Group as Vice President, Software Engineering.  We will
soon be a host on MilNet, so I have not established an interim
mailbox elsewhere.  Please direct any short-term mail to me via
Jerry at this address.

The recent flurry of messages about Wollongong requires a formal
response.  As you are aware, The Wollongong Group has been
selling TCP/IP-based products for some years.  While we have been
successful in doing so, we have been less successful in maintaining
an unblemished reputation within the Internet community.  Recently,
we began taking actions to improve user perceptions.  From a technical
standpoint, the most significant of these actions involves upgrades
to our VAX/VMS product called WIN/TCP, especially converting to the
use of 4.3BSD as a code base for the TCP/IP implementation.  By doing
so, many long-standing problems were solved and performance has been
substantially improved.

On reviewing the messages that were sent to this distribution list,
it appears that the basis for two of the three explicitly critical
notes was a) system administration errors, and b) the use of very
old software.

At the present time, the new release (3.0) does not have any major
TCP/IP bugs known to us, nor does it crash the operating system.  The
immediately previous version (2.3) has not had any bugs that crash
VAXes for a time longer that any Wollongong personnel can remember.

It is our policy to work closely with all users of our products to
satisfy their needs.  Mark Crispin's July 6 email message, while it
contained no specific details, has been partially addressed in a
public reply citing cockpit error, rather than faulty software.  The
message was sent by a system administrator whose contact with Mark
triggered Mark's note.  The system administrator cockpit error we
identified does not involve any software bugs, but it does result in
setting the hosts's own name to a constant ("Unknown").  To eliminate
this confusion, we are changing the software to simply use the text
version of the IP address, whenever a similar administrator error is
made.

As part of a test against one of the systems running Mark's TCP, we
did encounter a client SMTP bug.  WIN/TCP 3.1, which will be
released shortly, fixes it.  It was only discovered because of high
delay in the Arpanet, thereby causing an extraordinary timeout.

In addition to providing technically competent software, Wollongong must
provide support for our products.  This is critical.  Although admittedly
flawed in the past, this, too, is being significantly improved, as the
recent TCP/IP activity cited above demonstrates.  "Support" is a
separate product and has to be purchased.  There have been some customers
who purchased the TCP product but did not, for whatever reason, purchase
support.  They then passed on the product to the real end-users and
claimed, falsely, that we would not provide support.  The cited case of
our software crashing a VAX cluster appears to be an example of this.
Although we subsequently established direct contact with a portion of
the actual end-users affected in this way, we were unfortunately unable
to find the remainder.

The suggestion about our connecting the the Internet is extremely well-
taken.  Part of the reason I was asked to join Wollongong was to bring
some Internet experience in-house.  The wheels were already in motion,
I discovered, to get a connection when I came on-board.  We were
supposed to be on MilNet about 4 months ago, and are in the final
stages of debugging the telecom link.

Lastly, with regard to our AT&T version of TCP/IP...it should be noted
that we developed this product at the specification of AT&T and we are
not free to add features on our own (AT&T markets the product; we
do not).  Hence, please ask them to suggest to us any changes that you
deem appropriate.

Dave

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 17:33:56 EDT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re:  fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin


Sorry,  we don't have any system V.

				-- Sergio

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

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 19:00:11 EDT
From:      karn@FALINE.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet meltdowns

As I've said before, I think the notion of an "IP broadcast address" is
utterly meaningless. Broadcasting is a notion limited solely to certain
subnets; the Internet itself has no notion of broadcasting. (I'll ignore
the experimental multicast work for the time being).

Therefore it is completely bogus to look at anything other than the
SUBNET destination address when determining whether an incoming packet
is a broadcast or not. Getting an Ethernet packet with all 1's in the
destination field is both necessary and sufficient to label it as a
broadcast packet that must not be forwarded or answered with an ICMP
message even if the type field says it's an IP datagram. The IP address
field should be completely ignored; therefore it is irrelevant to even
specify a "standard" IP broadcast address.

It is arguable whether broadcast packets should even use UDP/IP at all,
although I suppose it is handy because of the port multiplexing and
checksumming provided by UDP.

Phil

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jul 87 21:45 EST
From:      <VIRGO%CUNYVMS1.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   tcp-ip for VAX/VMS

I am looking for a bare-bone Public Domian TCP/IP for the VAX/VMS
which could do the following for our Symbolics, and RT's

        1]  Receive mail and files from the outside world as mail
            and provide an equivalent of cftp from VAX to the RT's
            and send mail to Symbolics and RT's.

        2]  Let the Lisp Machine transfer files via the VAX to the
            RT's and other non VAX machines.

        3]  internal mail between the VAX's and non-VAX machines.

At present we have DECNET on the VAX and frankly as far as the the
Symbolics DNA for Decnet is concerned I am not too happy. Plus it is
not feasible for RT to send its code and files to LispM easily.

We do have tcp/ip for RT's and want the VAX 11/780 to be a go-between
the other machines so that outside mail could be routed to the other
machines.

Pointers to any Public Domian tcp/ip and who to get them would be greatly
appreciated.........................................

        Thanks in advance

                                                Anil Khullar
                                        {Ph.D. Prog in Psychology
                                         C.U.N.Y. Grad. Center.
                                        33 W 42 St. Box 295,
                                         New York NY 10036      }

BITNET:virgo@cunyvms1
INTERNET:virgo%cunyvms1.BITNET@wiscvm.edu
UUCP: ..columbia!cunygs!virgo {Tentative}
UUCP: virgo@cunygs.UUCP

==========================================================================
[DISCLAIMER: They say after Boston there is heaven, I agree; I say after
LispM there is nirvana, they don't. This and other opinion of mine are
held dearly by me, My employers and the institution I represent do not
necessarily hold that view. I am sole culprit of such fantasies. No living
being is responsible, however unsolicited support is welcome]

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Jul-87 22:45:00 EDT
From:      VIRGO@CUNYVMS1.BITNET
To:        comp.protocols.tcp-ip
Subject:   tcp-ip for VAX/VMS


I am looking for a bare-bone Public Domian TCP/IP for the VAX/VMS
which could do the following for our Symbolics, and RT's

        1]  Receive mail and files from the outside world as mail
            and provide an equivalent of cftp from VAX to the RT's
            and send mail to Symbolics and RT's.

        2]  Let the Lisp Machine transfer files via the VAX to the
            RT's and other non VAX machines.

        3]  internal mail between the VAX's and non-VAX machines.

At present we have DECNET on the VAX and frankly as far as the the
Symbolics DNA for Decnet is concerned I am not too happy. Plus it is
not feasible for RT to send its code and files to LispM easily.

We do have tcp/ip for RT's and want the VAX 11/780 to be a go-between
the other machines so that outside mail could be routed to the other
machines.

Pointers to any Public Domian tcp/ip and who to get them would be greatly
appreciated.........................................

        Thanks in advance

                                                Anil Khullar
                                        {Ph.D. Prog in Psychology
                                         C.U.N.Y. Grad. Center.
                                        33 W 42 St. Box 295,
                                         New York NY 10036      }

BITNET:virgo@cunyvms1
INTERNET:virgo%cunyvms1.BITNET@wiscvm.edu
UUCP: ..columbia!cunygs!virgo {Tentative}
UUCP: virgo@cunygs.UUCP

==========================================================================
[DISCLAIMER: They say after Boston there is heaven, I agree; I say after
LispM there is nirvana, they don't. This and other opinion of mine are
held dearly by me, My employers and the institution I represent do not
necessarily hold that view. I am sole culprit of such fantasies. No living
being is responsible, however unsolicited support is welcome]

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jul-87 03:03:12 EDT
From:      cetron%ced@CS.UTAH.EDU (Ed Cetron)
To:        comp.protocols.tcp-ip
Subject:   twg, and nic not knowing its domain name....


I tried to send an article into the tcp-ip mailing list (twice) and
I keep getting the mail back....(with some headers removed) here is
the letter and returned mail:

From MAILER-DAEMON@cs.utah.edu Thu Jul 16 00:58:47 1987
Date: Thu, 16 Jul 87 01:02:47 MDT
From: MAILER-DAEMON@cs.utah.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <cetron@utah-ced>
   ----- Transcript of session follows -----
550 <tcp-ip@nic.sri.com>... Host unknown

   ----- Unsent message follows -----
Date: Thu, 16 Jul 87 00:58:32 MDT
From: cetron@utah-ced (Ed Cetron)
Message-Id: <8707160658.AA06350@utah-ced.ARPA>
To: tcp-ip@nic.sri.com
Subject: twg and nic not knowing its domain name?


I recently tried to post to the tcp-ip newsgroup and had
this result:

>From MAILER-DAEMON@cs.utah.edu Wed Jul 15 23:30:05 1987
Date: Wed, 15 Jul 87 23:34:10 MDT
From: MAILER-DAEMON@cs.utah.edu (Mail Delivery Subsystem)
Message-Id: <8707160534.AA02006@cs.utah.edu>
Subject: Returned mail: Host unknown
To: cetron@cs.utah.edu
Status: RO

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

   ----- Unsent message follows -----
From: cetron (Edward J Cetron)
Message-Id: <8707160534.AA02003@cs.utah.edu>
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Wollongong TCP/IP for VAX/VMS
References: <8707152153.AA04238@ucbvax.Berkeley.EDU>
Reply-To: cs.utah.edu.uucp!cetron (Edward J Cetron)
Organization: Center for Engineering Design, Univ of Utah
Apparently-To: tcp-ip@nic.sri.com

	Well, I for one have been one of the more vociferous critics of
the WIN/VX product for quite some time.  I have seen too many sites complain
of brain-damage and poor support.  In addition, we ran the 2.3 version against
the Tek-CMU code and the WIN/VX just couldn't cut it.

	HOWEVER, given the current number of sites running 3.0 and saying it
is quite capable, and the kind of response TWG has been putting forth 
(witness Dave Crocker's article) and the very good experience support-wise
reported from new 3.0 sites, I think I might reserve judgement. 

	Now, if only they can make it as inexpensive as the Tek-CMU code
	:-).......

-ed cetron
cetron@cs.utah.edu





nic.sri.com is in the host tables, it nic just not answering right???

-ed
cetron@cs.utah.edu

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jul-87 03:45:52 EDT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   Re: twg, and nic not knowing its domain name....

NIC.SRI.COM is not and was never the official name of any host.
-------

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jul-87 06:13:38 EDT
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  Routers and Internet Protocol #77

John, I tend to agree with you.  IP routers need to be kept simple
under the current architectural concepts.

dennis
-------

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jul 87 10:22:20 -0400
From:      Mike Brescia <brescia@CCV.BBN.COM>
To:        Mark Lottor <MKL@SRI-NIC.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@CCV.BBN.COM
Subject:   Name of NIC (was: twg, and nic not knowing its domain name..)

     NIC.SRI.COM is not and was never the official name of any host.

SRI-NIC.ARPA is equally hard to remember.  I suggest that NIC be a name at the
top level of the domain tree, and be the obvious place.  The reason is that
the Net.Info.Ctr is a top level resource, not actually some branch of SRI.COM.
Suppose SRI changes its corporate name?  Suppose ARPA removes its support of
the internet, and the ARPA domain goes away?  The (THE) NIC service should
still be available by name.

Mike.
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jul 87 16:06:33 -0700
From:      Thomas Eric Brunner <brunner@spam.istc.sri.com>
To:        tcp-ip@sri-nic.arpa
Cc:        desiree@kl.sri.com, brunner@kl.sri.com, kashtan@stripe.sri.com
Subject:   Re: TCP-IP on VMS from SRI
The Right Person is desiree@kl.sri.com. Some relevent traffic included
below for context.

------- Forwarded Message
>In article <353@louie.udel.EDU>, Joel Garrett (garrett@udel.EDU) writes:
>
>> I've been hearing a lot of talk about a VMS implementation of TCP/IP
>> from either Tektronix or SRI.  Who can I get in contact with for more
>> information about this product?
>
>Some time back, I was asked this question by mail.  After a bit of
>calling around inside Tektronix, I wound up talking to The Right Person.
>The answer (for the Tektronix software) is, "Call your local Tektronix
>field office."  (I don't know the answer for SRI.)
>
>					Steve Rice
>
------- End of Forwarded Message

------- Forwarded Message
>We have been using TWG on our VMS VAXs in a subnetted environment without 
>problems major problems for almost two years.  In fact, for about 6 months, 
>we used a VAX8600 running VMS4.2 and TWG to drive two ethernets and 4 T1 lines,
>until we switched to ULTRIX, ( I was not in favor of using a VAX/VMS as an
>ip gateway but at that time we had no choice ).
>
>					-- Sergio
------- End of Forwarded Message

/teb
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jul-87 08:32:46 EDT
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet meltdowns

> The people who
> will be implementing ISO are exactly the same people who have ignored
> the TCP/IP implementation guidelines.  If people can do IP's that
> don't respond to ICMP echo ... 

At least in theory, this is not the way it is supposed to work.  A principal 
reason for eventually converting to ISO protocols is that they will be 
off-the-shelf, conforming products freely available from all vendors, 
where `conformance' is meant to imply both adherence to the standard 
and interoperation between vendor implementations.

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jul-87 09:30:00 EDT
From:      Crawley@ALDERAAN.SCRC.SYMBOLICS.COM (Eric S. Crawley)
To:        comp.protocols.tcp-ip
Subject:   SCRC Ethernet change

[Please excuse the wide distribution I know this shouldn't be
necessary.]

On Saturday, July 18th, the SCRC ethernet will change from 192.10.41.0
to 128.81.41.0.  The appropriate changes were put into the NIC Host
table on Wednesday July 15th.  

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jul-87 10:48:52 EDT
From:      charny@GATEWAY.MITRE.ORG (M. Charny)
To:        comp.protocols.tcp-ip
Subject:   Re: PD TCP/IP requests


Pat,

I have sent the following information to several people who have
asked about this.  I hope it is helpful to you.

Manette Charny

                    -+-+-+-+-+-+-+-+-+-+-+-

The MITRE Corporation has produced several prototype implementations of
devices using the Department of Defense (DoD) communication protocols
TCP, IP, ARP, ICMP, and TELNET.  Most of the implementations use the
CMOS/DMOS operating systems also produced by MITRE.  The programs are
written in "C" language and Motorola 68000 assembler.  The programs
are maintained on a SUN3 workstation running Berkely 4.2 UNIX.

MITRE is not in the business of distributing or maintaining software.  Devices
and software created by MITRE are prototypes created for particular sponsors.
The programs are available to the outside world according to the conditions
and procedures listed below.  **Please note that distribution is done on
a time available basis and therefore delivery turn-around time cannot
be guaranteed.**

The software is distributed free of charge.  In order to obtain
a copy of this software, the requester should send to one of the
below listed people:

1.  2400 foot reel of 1/2 inch magnetic tape capable of handling 1600 bpi.

2.  Letter, on your company letterhead, indicating the following:
	-- who they are
	-- short synopsis (2-3 sentences) about
		what our software is to be used for
	-- equipment and operating system being used by them.
	-- tape format desired:
		only format possible is Berkely 4.2 UNIX tar, 1600 bpi,
		and any blocking factor 1 through 20. (20 by default)
	-- they agree to the four conditions listed below 
		(please explicitly list the conditions in the letter).


		i.  The MITRE TCP/IP source files will not be passed on to
			any third party.

		ii.  MITRE will be credited should the software be used
			in a product or written about in any publication.
			However, MITRE will not be referenced as the 
			source in advertisements.

		iii.  MITRE assumes no legal responsibility for source
			code and its subsequent use.  No warranty is
			expressed or implied.

		iv.  If any bugs or problems are found they will
			be reported back to MITRE.

NOTE: These programs are not commercial quality, but do work.
  A good 'hacker' can learn to build 'boxes' by studying the 'config',
  'table', and 'Makefiles' in the directories 'box/diag/testV',
  'box/testV/1822', 'box/hfe', and 'box/gate_egp'.

The current contact(s) for the TCP/IP distribution tape are:

		Manette Charny
		Mailstop: W425
		1820 Dolley Madison Blvd.
		McLean, VA 22102
		(703) 883-6728
		ARPANET:   charny@mitre-gateway

		Daryl Crandall
		Mailstop: W429
		1820 Dolley Madison Blvd.
		McLean, VA 22102
		(703) 883-7278
		ARPANET:   daryl@mitre-gateway


Documents describing the OS and the TCP/IP implementation can be obtained
from MITRE document control.

	"CMOS, A Portable Operating System in C"
	Gilbert R. Berglass
	MITRE Technical Report:  MTR-84W00071

	"DMOS, A Portable Distributed Operating System in C"
	Shiraz G. Bhanji
	MITRE Technical Report:  MTR-85W00206

	"Implementation of the BBN 1822 Host-to-IMP Protocol in a CMOS
	Environment"
	Manette Charny
	MITRE Working Paper:  WP-84W00223

	"The MITRE Implementation of MIL-STD 1777: The Internet Protocol"
	William S. Morgart
	MITRE Working Paper: WP-86W??? (not released yet!)

	"TCP/IP" Interface Specifications for CMOS Systems"
	Daryl O. Crandall
	MITRE Working Paper: WP-86W00180

	"TCP/IP" Diagnostic Package for CMOS Systems"
	Daryl O. Crandall
	MITRE Working Paper: WP-86W??? (not released yet!)

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jul-87 12:04:00 EDT
From:      barry@confusion.UUCP (Barry Lustig)
To:        comp.protocols.tcp-ip
Subject:   PD TCP/IP requests

A "mini" TCP/IP was once posted to comp.sources.unix.  You may want to
look at the archives on uunet.uu.net.

Barry Lustig
Cognitive Science Lab
Princeton University

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jul-87 18:44:36 EDT
From:      weltyc@NIC.NYSER.NET (Christopher A. Welty)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for VMS


	The Tek TCP/IP for VMS was sort of taken over by cmu, I
believe, it still legally belongs to Tektronics, but CMU has spiced it
up a lot.  There is a special mailing list for the tektronic tcp/ip
called tektcp, ummm let's see, send a msg to:

	tektcp-request%kla.weslyn%wesleyan.bitnet@wiscvm.wisc.edu

to get added.  There's probably a shorter way to write it, but that's
all I have....

---

Christopher Welty - Asst. Director, RPI CS Labs
weltyc@cs.rpi.edu       ...!seismo!rpics!weltyc

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Jul-87 23:41:14 EDT
From:      CDRNI@CUNYVM.BITNET ("George N. Reeke Jr.")
To:        comp.protocols.tcp-ip
Subject:   NETWATCH

Can someone out there tell me how to get a copy of
NETWATCH for IBM PC (or some similar program to
analyze ETHERNET traffic)?  Thanks, GNR

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jul 87 23:41:14 EDT
From:      "George N. Reeke Jr." <CDRNI%CUNYVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   NETWATCH
Can someone out there tell me how to get a copy of
NETWATCH for IBM PC (or some similar program to
analyze ETHERNET traffic)?  Thanks, GNR
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 04:55:49 EDT
From:      dpk@BRL.ARPA (Doug Kingston)
To:        comp.protocols.tcp-ip
Subject:   Something has changed dramatically


	Internet performance has soared to some of the best I have
see all year.  I have been able to successfully access Berkeley and
UCL is finally available again.  I would like to thank whoever is
responsible for the recent change of events and to suggest that
perhaps a status update is in order.

Putting away my UUCP,
	-Doug-

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 87 09:18:13 -0500
From:      Steve Cohn <scohn@ALEXANDER.BBN.COM>
To:        Doug Kingston <dpk@BRL.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, scohn@ALEXANDER.BBN.COM
Subject:   Re: Something has changed dramatically

Here's something that changed. BBN modified the metric used for calculating SPF
routes in the Arpanet on Sunday, 12 July. A detailed description and analysis
of how it works and a report on measured changes in performance in the Arpanet
will be forthcoming eventually. In brief, this change in the metric leads to
more stable routing behavior when the network is overloaded, thereby reducing
the tendency for congestion to spread from overloaded paths to the rest of the
network. This modification also tends to make satellite trunking more
attractive.

Other potential sources for improvement include recent topology changes
including the addition of transcontinental VSAT trunks between MIT-77 and
SRI-51. These trunks became operational about 1 July.

The routing effort is still in the experimental/tuning stage. We expect that
performance on many PSN-to-PSN flows will be improved by this modification. It
is also possible that some PSN-to-PSN flows will receive degraded performance.
We at BBN would like to hear both the good news and the bad news. Please send
your observations about recent changes in internet/Arpanet performance to Fred
Serr (fserr@bbn.com), Bob Pyle (rpyle@bbn.com) and myself (scohn@bbn.com) and I
suppose to the list if your observation is of general interest.

Stephen Cohn
Director of Network Analysis
BBN Communications
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 87 09:31:28 -0400
From:      Robert Hinden <hinden@CCV.BBN.COM>
To:        CERF@A.ISI.EDU
Cc:        dpk@BRL.ARPA, tcp-ip@SRI-NIC.ARPA, hinden@CCV.BBN.COM
Subject:   Re: Something has changed dramatically
Vint, Doug,

Its not voodoo networking, but lots of hard work.  There have been
several changes on the Arpanet (new line and a software patch) which
make things better.  These changes are very recent.  A more detailed
report will be seen soon.

Regards,
Bob

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 06:59:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Something has changed dramatically

Doug,

Voodoo networking! (George Bush theme for the 88 campaign?)

Maybe someone sacrificed a chicken over RFC 1009?

Added some links?

Your puzzlement points out that we lack any global view of the
Internet and don't even have a good way to figure out when we
should report changes we've made in some part of the system or
to whom such changes should be reported.

Sounds like a good INENG topic, to me.

Vint

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 87 10:10:36 -0400
From:      Mike Brescia <brescia@CCV.BBN.COM>
To:        "George N. Reeke Jr." <CDRNI%CUNYVM.BITNET@WISCVM.WISC.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@CCV.BBN.COM
Subject:   Re: NETWATCH
     NETWATCH for IBM PC (or some similar program ...

TCPDUMP for Suns is also useful for checking traffic patterns.  It does lack
the real-time interface that NETWATCH has.  Van Jacobson (van@lbl-csam.arpa)
made this available from one of his hosts.

    mike
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 09:42:59 EDT
From:      scohn@ALEXANDER.BBN.COM (Steve Cohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Something has changed dramatically


Here's something that changed. BBN modified the metric used for calculating SPF
routes in the Arpanet on Sunday, 12 July. A detailed description and analysis
of how it works and a report on measured changes in performance in the Arpanet
will be forthcoming eventually. In brief, this change in the metric leads to
more stable routing behavior when the network is overloaded, thereby reducing
the tendency for congestion to spread from overloaded paths to the rest of the
network. This modification also tends to make satellite trunking more
attractive.

Other potential sources for improvement include recent topology changes
including the addition of transcontinental VSAT trunks between MIT-77 and
SRI-51. These trunks became operational about 1 July.

The routing effort is still in the experimental/tuning stage. We expect that
performance on many PSN-to-PSN flows will be improved by this modification. It
is also possible that some PSN-to-PSN flows will receive degraded performance.
We at BBN would like to hear both the good news and the bad news. Please send
your observations about recent changes in internet/Arpanet performance to Fred
Serr (fserr@bbn.com), Bob Pyle (rpyle@bbn.com) and myself (scohn@bbn.com) and I
suppose to the list if your observation is of general interest.

Stephen Cohn
Director of Network Analysis
BBN Communications

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 09:56:04 EDT
From:      hinden@CCV.BBN.COM (Robert Hinden)
To:        comp.protocols.tcp-ip
Subject:   Re: Something has changed dramatically

Vint, Doug,

Its not voodoo networking, but lots of hard work.  There have been
several changes on the Arpanet (new line and a software patch) which
make things better.  These changes are very recent.  A more detailed
report will be seen soon.

Regards,
Bob

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 10:26:47 EDT
From:      brescia@CCV.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: NETWATCH


     NETWATCH for IBM PC (or some similar program ...

TCPDUMP for Suns is also useful for checking traffic patterns.  It does lack
the real-time interface that NETWATCH has.  Van Jacobson (van@lbl-csam.arpa)
made this available from one of his hosts.

    mike

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 12:31:00 EDT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Something has changed dramatically

The third transcontinental link (MIT77 <=> SRI51) came online about
two weeks ago.  I noticed a serious DECREASE in performance just after
the link came up, but now I too am seeing a major performance
improvement (it's been a long time since I could FTP from MIT to
Stanford at noon on a Friday!).

My guess is that there were some initial tuning problems after the new
link came up; not too surprising given that this is a satellite bounce
instead of a land line.

Presumably somebody at BBN can give a more detailed report.

--Rob

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 14:16:02 EDT
From:      brian@casemo.UUCP (Brian Cuthie )
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for VAX/VMS

In article <432@umbc3.UMD.EDU>, jeff@umbc3.UMD.EDU (Jeffrey Burgan) writes:
> In article <12316245218.8.MRC@PANDA> MRC@PANDA.COM (Mark Crispin) writes:
> >
> >     I received my nth bug report from a Wollongong site today complaining
> >that mail didn't work between them and a DEC-20.
> >
> >     The problem is, of course, that the Wollongong software simply does
> >not work ... and that Wollongong simply does not care.
> 
>    We have been running Wollongong's software for 2 years and have 
> never experienced any problems sending to a TOPS-20 machine.

...

> What would you have VMS user's use?
>     

UNIX of course !!


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Cuthie
CASE (Rixon) Communications
Columbia Md. 21046

(301) 290 - 7443

ARPA:	Brian@umbc3.umd.edu
UUCP:	...seismo!mimsy!aplcen!casemo!brian

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 14:21:43 EDT
From:      schoff@NIC.NYSER.NET (Martin Lee Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   TWG questions


I have two questions concerning the current (3.X) implementation:

	1) does it still support the async tcp/ip code
		(ttylink in WIN/VX 2.2)
	2) Does anyone have a DECNET async connection where they
		use DBRIDGE, and what is the performance like?

Marty

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 14:44:03 EDT
From:      PADLIPSKY@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Uselessness

[The following got to John, but not to the List, thanks to the vagaries
of trying to Answer on his foreign To and CC fields:]

John--
   As I understand your msg, "the PTT way" amounts to Overcharge So That
You Can Overengineer.  The Internet way, however, doesn't have to be
Undercharge And You Must Underengineer.  How about, instead, Undercharge
And You'd Better Engineer A Lot More Cleverly?  For example, I recall
that in the Multics NCP [sic] I had a privileged primitive that let me
ignore packets from a Host on a blacklist at interrupt time (which was
actually used once, during the infamous Network Horror Story Number 5):
Why not use a similar trick in Gateways?  Say, on a 30-second cycle (or
whatever time value seems appropriate) check the per-Host packet counters
(added for the purpose) and put any Host that's exceeded a threshold
count on the List for the next cycle.   A tad arbitrary, perhaps, but
much easier to implement than trying to spot and throttle sf-lovers file
transfers/SMTPs.  (The threshold should probably be a fraction of
total packets for the period rather than a set number, so that periods
of relative inactivity for other Hosts behind the Gateway can be
catered to--but this is just a "frinstance," not a spec, so no matter.)
   The example isn't necessarily to be taken literally, of course; it's
just meant to suggest a principle to the effect that you can combat
resource hogging creatively without violating protocol (since Gateways
are explicitly allowed to drop packets on the floor) on the one hand
yet without having to "go commercial" on the other hand.
   Actually, I've long suspected that the real problem with the
Internet Way is that we draw so heavily on Academe that clever
engineering is somehow suspect because it's not Computer Sciencey
enough somehow.  I mean, granted we couldn't have afforded to throw
as much hardware as we might have liked at Gateways from the outset,
but it still seems to me that all the pious queuing-theoretic stuff
about one buffer is enough and even infinite buffers aren't enough
and the like has clouded the issue so much that we still (unless
the relevant Task Force is about to step in) haven't come up with
a rough and ready congestion control approach because we "know"
it wouldn't be "optimal".  Well, as I've said before Optimality
Differs According To Context.
   cheers, map
P.S.  As I recall, the X.25 spec certainly _implies_ that there won't
be any dynamic routing, both in one of the error returns and, for that
matter, in the whole "virtual circuit" premise (since destination addrs
aren't carried in ordinary packets), but, yes, They could do it right
despite all that if They had/wanted to.  Does anybody know of an
implementations that do do it right, though?  (And even if there are some,
so what?  We could have some segments of the Internet which used
Multics Gateways if we wanted/had to.  Some old saw about weakest links
still seems to apply....)
-------

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 16:24:31 EDT
From:      wrk@abvax.UUCP
To:        comp.protocols.tcp-ip
Subject:   Wollongong telnet and new line processing

I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS
system using Wollongong telnet and have discovered an interesting
problem. Unix uses \n as the line terminator, but VMS interpetes
that as 'delete the word to the left of the cursor'. So imagine
this:
	% telnet vms_node

	Username: GUEST
		       ^
		       and here you type a return.

Unix translate the \r into a \n and sends it across the net
to the VMS machine which promptly deletes the word GUEST. This
makes logging in a little difficult.

I've modified telnet to send a \r instead of a \n for the line
terminator. Although I think this is only a work around.

I say this because if you are connect to the Unix machine
via a direct line everything works fine. This problem only
occurs when you are connected via a pty. We use Bridge
cs/1 terminal servers almost exclusivly, hence you are always
connected to a pty and never to a direct line. 

This leads me to think that the problem lies somewhere in the
pty driver. Anyone have any ideas? 

Thanks
Bill King
...!{pyramid,decvax}!abic!wrk

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 16:27:36 EDT
From:      braden@BRADEN.ISI.EDU (Bob Braden)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet meltdowns

Phil,

Your interpretation of the IP broadcast address situation is at variance
from the "official" interpretation in RFC-1009.  The issue is one on
which reasonable and informed Internetters can and have disagreed,
on this mailing list and elsewhere, and there probably is not a "right"
answer.  However, we did make a decision, and gave the Internet community
plenty of chance to read and comment on RFC-1009 before it was
published. As a matter of fact, the IP broadcast address was not
an issue on which anybody made a comment (and there WERE plenty of
comments and commenters on the RFC-985+ draft!).

I suspect that you will now go read RFC-1009, and be suitably outraged.
All outraged messages to Jon Postel or myself on the contents of RFC-1009
will be read, considered carefully, and if the arguments are irrefutable,
will influence a future revision to the RFC.

   Bob Braden


PS I think you make a mistake by dismissing the IP multicasting mechanism.
A 4.3BSD implementation is available today for anyone who wants it.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 17:04:33 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Ethernet meltdowns

Phil,

Read RFC-985 and its recent successor. The IP address space is not flat.
There are architected IP broadcast (and other) addresses, whether bogus
or not. The intent of the martian filter is to kill "local" broadcasts
before they escape the local net. This is a pragmatic consideration
based on some years of horror living without it.

Dave

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Jul-87 23:02:51 EDT
From:      jch@OMNIGATE.CLARKSON.EDU (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: twg, and nic not knowing its domain name....


>
>I tried to send an article into the tcp-ip mailing list (twice) and
>I keep getting the mail back....(with some headers removed) here is
>the letter and returned mail:
>
>	...
>
>nic.sri.com is in the host tables, it nic just not answering right???

No, nic.sri.com is not in the host tables that I have, #648.  The
authoritive servers for sri.com, kl.sri.com and stripe.sri.com, both
claim that it does not exist.  It looks like that alias was removed,
the question is, was it intentional?

Jeff

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jul 87 23:02:51 EDT
From:      Jeffrey C Honig <jch@omnigate.clarkson.edu>
To:        Ed Cetron <cetron%ced@cs.utah.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: twg, and nic not knowing its domain name....

>
>I tried to send an article into the tcp-ip mailing list (twice) and
>I keep getting the mail back....(with some headers removed) here is
>the letter and returned mail:
>
>	...
>
>nic.sri.com is in the host tables, it nic just not answering right???

No, nic.sri.com is not in the host tables that I have, #648.  The
authoritive servers for sri.com, kl.sri.com and stripe.sri.com, both
claim that it does not exist.  It looks like that alias was removed,
the question is, was it intentional?

Jeff
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jul-87 03:18:55 EDT
From:      Eugene.Hastings@MORGUL.PSC.EDU
To:        comp.protocols.tcp-ip
Subject:   X.25 on vax (was: Vaxes and the System 38)~r

There exists a DEC package called PSI that provides X.25 communications.
We have a pair of VMS 8650s connected to GTE TELENET in this manner.
It required a special (fairly smart) interface, also DEC.

Gene Hastings
Pittburgh Supercomputing Center

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jul-87 06:41:51 EDT
From:      brescia@CCV.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Name of NIC (was: twg, and nic not knowing its domain name..)


     NIC.SRI.COM is not and was never the official name of any host.

SRI-NIC.ARPA is equally hard to remember.  I suggest that NIC be a name at the
top level of the domain tree, and be the obvious place.  The reason is that
the Net.Info.Ctr is a top level resource, not actually some branch of SRI.COM.
Suppose SRI changes its corporate name?  Suppose ARPA removes its support of
the internet, and the ARPA domain goes away?  The (THE) NIC service should
still be available by name.

Mike.

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jul-87 07:33:19 EDT
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Name of NIC (was: twg, and nic not knowing its domain name..)

Mike, I agree with you.  The NIC should be availabe by name, regardless
of where it is located.

dennis
-------

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jul-87 10:31:00 EDT
From:      M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon)
To:        comp.protocols.tcp-ip
Subject:   Name of NIC (was: twg, and nic not knowing its domain name..)

It's a neat idea, but the main problem with that is that there is already
another NIC (I'm speaking of nic.nyser.net).

--jsol

p.s. also there is a BITNIC in the BITNET namespace.

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jul-87 16:29:34 EDT
From:      M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon)
To:        comp.protocols.tcp-ip
Subject:   another joke.

"don't talk about networking in front of the kids".
-------

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jul-87 16:32:55 EDT
From:      M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon)
To:        comp.protocols.tcp-ip
Subject:   my last message

If you don't get it, don't worry. I sent it to the wrong list.


		o

			o

				p

					s

sorry folks,
--jsol
-------

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jul-87 20:14:26 EDT
From:      isns01@ms3.UUCP (Jim Chappell)
To:        comp.protocols.tcp-ip
Subject:   Gateway problem


We are running vanilla 4.2BSD on Vaxen 11/780s.
We use DEC DR-11 Direct Memory Access hardware connected to an Ungermann-Bass
NIU-150 to implement TCP/IP over a broadband LAN.
One of our Vaxen (hostname 'tlog') has a ACC DH/LH  + modem connected to 
PSN 76 to implement milnet access.  A representative interior VAX is 'ms3'.

Visually, we have:
---------                       ---------
| ms3   |                       | tlog  |
|       |                       |       |---\/\/---PSN 76--------| milnet |
 ---|-----                       ---|----
   |                               |
 ------                          -------
|NIU  |				| NIU |
--|----				---|---
--|--------------------------------|---------------------
---------------------------------------------------------


My problem exists on hosts interior to 'tlog'
I have been unable to access the milnet directly from such hosts.
Can anyone help me out?  Also, what's the best documentation to use
to get a handle on this beast?


The ifconfig we use on ms3 is:

/etc/ifconfig ub0 -trailers arp 92.0.0.6

Here's a script(1) output of what I've tried:


Script started on Sat Jul 18 19:39:08 1987
ROOT(ms3) 1: netstat -r
Routing tables
Destination     Gateway         Flags    Refcnt Use        Interface
loopback        127.0.0.1       U        0      0          lo0
92.0.0          ms3             U        0      7269       ub0
ROOT(ms3) 2: route add default tlog 0
add 0.0.0: gateway tlog, flags 1
ROOT(ms3) 3: netstat -r
Routing tables
Destination     Gateway         Flags    Refcnt Use        Interface
default         tlog            U        0      0          ub0
loopback        127.0.0.1       U        0      0          lo0
92.0.0          ms3             U        0      7270       ub0
ROOT(ms3) 4: whosis Chappell
whois: connect: Connection timed out
ROOT(ms3) 5: netstat -r
Routing tables
Destination     Gateway         Flags    Refcnt Use        Interface
default         tlog            U        0      11         ub0
loopback        127.0.0.1       U        0      0          lo0
92.0.0          ms3             U        0      7273       ub0
ROOT(ms3) 6: ^D  
script done on Sat Jul 18 19:41:08 1987
Script started on Sat Jul 18 20:07:29 1987
ROOT(ms3) 1: route add sri-nic tlog 1
add sri-nic: gateway tlog, flags 7
ROOT(ms3) 2: netstat -r
Routing tables
Destination     Gateway         Flags    Refcnt Use        Interface
sri-nic         tlog            UGH      0      0          ub0
default         tlog            U        0      11         ub0
loopback        127.0.0.1       U        0      0          lo0
92.0.0          ms3             U        0      7387       ub0
ROOT(ms3) 3: whois Chappell
whois: connect: Connection timed out
ROOT(ms3) 4: netstat -r
Routing tables
Destination     Gateway         Flags    Refcnt Use        Interface
sri-nic         tlog            UGH      0      11         ub0
default         tlog            U        0      11         ub0
loopback        127.0.0.1       U        0      0          lo0
92.0.0          ms3             U        0      7390       ub0
ROOT(ms3) 5: ^D  
script done on Sat Jul 18 20:09:00 1987
-- 
Jim Chappell  ...!seismo!vrdxhq!ms3!jrc 
ISN Corp.	(703) 979-8900
1235A Jeff Davis Hwy, Suite 220
Arlington, Va 22202

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Jul-87 22:52:42 EDT
From:      weltyc@NIC.NYSER.NET (Christopher A. Welty)
To:        comp.protocols.tcp-ip
Subject:   Something has changed dramatically


	Hard work indeed.  I too have noticed significant improvement
in ARPAnet performance.  THose resposible should be congratulated!

---

Christopher Welty - Asst. Director, RPI CS Labs
weltyc@cs.rpi.edu       ...!seismo!rpics!weltyc

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19-Jul-87 00:13:37 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Name of NIC (was: twg, and nic not knowing its domain name..)

Jon,  I think that Mike and Dennis were thinking of the name
of the entity to be NIC (or .NIC to be syntatically incorrect).
Dan
-------

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1987 00:13:37 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Jon Solomon <@EDDIE.MIT.EDU:M.JSOL@DEEP-THOUGHT.MIT.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Name of NIC (was: twg, and nic not knowing its domain name..)
Jon,  I think that Mike and Dennis were thinking of the name
of the entity to be NIC (or .NIC to be syntatically incorrect).
Dan
-------
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19-Jul-87 17:48:17 EDT
From:      ROODE@BIONET-20.ARPA (David Roode)
To:        comp.protocols.tcp-ip
Subject:   Re: Name of NIC (was: twg, and nic not knowing its domain name..)

WaWhat about creating a domain under the top level NET domain,
NIC.NET  in there could be the name DDN.NIC.NET for
the DDN NIC......  NYSER.NIC.NET for their NIC....
This also works for the NOC.... ARPANET.NOC.NET  MILNET.NOC.NET
etc.  The NIC/NOC for the NSFNET is called NNSC for some reason,
so NSFNET.NNSC.NET is also possible.
-------

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19-Jul-87 20:53:58 EDT
From:      ROMKEY@XX.LCS.MIT.EDU (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: NETWATCH

NETWATCH is part of the PC/IP package from MIT. You can get a copy of it
by contacting:
	MIT Microcomputer Center
	Room 11-209
	77 Massachusetts Avenue
	Cambridge, MA  02139
	(617) 253-6325

It has drivers for the 3COM 3C500/3C501 ethernet interface, the Micom-Interlan
NI5010 ethernet interface and the Proteon p1300 ProNET-10 interface.
					- john romkey
-------

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19-Jul-87 22:50:37 EDT
From:      schoff@NIC.NYSER.NET (Martin Lee Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   Re:  Name of NIC (was: twg, and nic not knowing its domain name..)

Actually there is a "nic.isi.edu" also.

Reading between the lines is sri-nic.arpa suppose to become:

	nic.ddn.net

Or some such thing?

Marty

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19-Jul-87 23:59:01 EDT
From:      doug@wapsyvax.OZ (Doug Robb)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   NFS for 4.{2,3}

Can anyone tell me if they are aware of or have
public domain or cheapish NFS software (al la SUN's)
that will run on a 4.{2,3} BSD system.
Thanks

ARPA net :	doug%wapsyvax.oz@seismo.css.gov
UUCP	:	....!{seismo,mcvax,ucb-vision,uks}!munnari!wacsvax.oz!doug

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 00:00:13 EDT
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Clearpoint


I noticed that some assistance was being to get Wollongong on the
net.  I was talking to Vinnie Bono who is the President of Clearpoint
which makes lots of useful boards for VAXes and other machines.
Apparently a lot of Clearpoint clients have net access and he would
like to get some access so that he can be more responsive to his
clientel.  If anyone can give some advice or give some assistance, it
would be much appreciated.

Yakim Martillo

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1987 05:53-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        brescia@CCV.BBN.COM
Cc:        MKL@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Name of NIC (was: twg, and nic not knowing its domain na...
Guys,  to  forestall  further  discussions  on  this.   The  name
"SRI-NIC.ARPA" is the official name for the NIC now and  this  is
due  mostly  to  historical concerns.  At some time in the future
(i.e.  when I can spare the time to argue the case at  the  PMO),
the  NIC will change to something like NIC.DDN.MIL.  (No, I don't
want naming suggestions just yet thanks!)

Mike
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 06:46:49 EDT
From:      schoff@NIC.NYSER.NET (Martin Lee Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   Re: Name of NIC (was: twg, and nic not knowing its domain name..)

Actually the NOC for the NSFNet is called devvax.tn.cornell.edu.

marty

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jul 87 09:44:49 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        PADLIPSKY@A.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: Internet Uselessness
Mike,

As a whole, I think the internet community has been doing "clever
engineering" for quite a number of years now.  However, there
comes a time when offered load just overwhelms the resources
devoted to the task.  We are very close to that point on the
ARPANET, even though we just made the routing algorithm more
"clever" and added another transcontinental trunk.

We are currently in the process of implementing congestion
control in the PSNs.  This should optimize the total available
throughput of the network (at the expense of backing flows into
source hosts if necessary).

Finally, the X.25 spec really says nothing about what goes on in
the subnet, it is just an interface spec between a DTE and its
DCE.  Internally, the PSNs use virtual circuits to support both
AHIP (1822) and X.25 traffic while using good old dynamic
adaptive routing to get the packets between the endpoint PSNs.
Internally, neither AHIP nor X.25 data packets contain full
addressing information, just the destination PSN number and a
connection identifier at that PSN.  So I guess you might say that
we "do it right".

Cheers,
Andy
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 08:29:02 EDT
From:      lazear@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   TWG on MILNET?

Can someone please explain why TWG will be homed on the MILNET instead
of the ARPANET?  Somewhere the MIL in MILNET must have gotten redefined!
	Walt Lazear

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 08:53:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Name of NIC (was: twg, and nic not knowing its domain na...

Guys,  to  forestall  further  discussions  on  this.   The  name
"SRI-NIC.ARPA" is the official name for the NIC now and  this  is
due  mostly  to  historical concerns.  At some time in the future
(i.e.  when I can spare the time to argue the case at  the  PMO),
the  NIC will change to something like NIC.DDN.MIL.  (No, I don't
want naming suggestions just yet thanks!)

Mhing

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jul 87 11:45:51 -0400
From:      Mike Brescia <brescia@CCV.BBN.COM>
To:        Jim Chappell <vrdxhq!ms3!isns01@seismo.CSS.GOV>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@CCV.BBN.COM
Subject:   Re: Gateway problem
     I have been unable to access the milnet directly from such hosts.
     /etc/ifconfig ub0 -trailers arp 92.0.0.6

Jim,

Ask yourself the following question:

How will other hosts on the MILNET, and other gateways farther away, know how
to reach net 92?

You should go to your provider of operating system software, which you said is
4.2BSD unix, and ask them about configuring the gateway software for this
setup.  The key to answering the question I posed above is the program which
handles the "Exterior Gateway Protocol" (EGP), which should be provided as
part of your network software.

Also, you need to address the NIC to get a registered network number for your
Ungermann-Bass net, as well as an Autonomous System number (related to the
EGP).  Send your inquiry to 'hostmaster@sri-nic.arpa'.

Mike
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 10:09:32 EDT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Uselessness

Mike,

As a whole, I think the internet community has been doing "clever
engineering" for quite a number of years now.  However, there
comes a time when offered load just overwhelms the resources
devoted to the task.  We are very close to that point on the
ARPANET, even though we just made the routing algorithm more
"clever" and added another transcontinental trunk.

We are currently in the process of implementing congestion
control in the PSNs.  This should optimize the total available
throughput of the network (at the expense of backing flows into
source hosts if necessary).

Finally, the X.25 spec really says nothing about what goes on in
the subnet, it is just an interface spec between a DTE and its
DCE.  Internally, the PSNs use virtual circuits to support both
AHIP (1822) and X.25 traffic while using good old dynamic
adaptive routing to get the packets between the endpoint PSNs.
Internally, neither AHIP nor X.25 data packets contain full
addressing information, just the destination PSN number and a
connection identifier at that PSN.  So I guess you might say that
we "do it right".

Cheers,
Andy

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 11:47:36 EDT
From:      kp@hjuxa.UUCP (Karen Paszamant)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Streams TCP/IP


Does anyone know what vendors have a System V Release 3.0
streams based tcp/ip product?  The only vendors I have found
so far are Lachman Assoc. & Wollongong.  There must be others.

Thanks, in advance

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 12:33:40 EDT
From:      bjp@MITRE-BEDFORD.ARPA
To:        comp.protocols.tcp-ip
Subject:   SMTP for any UNIX on any kind of AT


Folks I need some help.  Is there anyone out there that has mil stnd
simple mail runing on any version of an AT under any version of UNIX?
If so, please let me know what versions and the vendors where you bought
it, there names addresses and phone numbers.  I need the answer by
tomorrow afternoon.

					bj Pease

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 12:41:05 EDT
From:      brescia@CCV.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Gateway problem


     I have been unable to access the milnet directly from such hosts.
     /etc/ifconfig ub0 -trailers arp 92.0.0.6

Jim,

Ask yourself the following question:

How will other hosts on the MILNET, and other gateways farther away, know how
to reach net 92?

You should go to your provider of operating system software, which you said is
4.2BSD unix, and ask them about configuring the gateway software for this
setup.  The key to answering the question I posed above is the program which
handles the "Exterior Gateway Protocol" (EGP), which should be provided as
part of your network software.

Also, you need to address the NIC to get a registered network number for your
Ungermann-Bass net, as well as an Autonomous System number (related to the
EGP).  Send your inquiry to 'hostmaster@sri-nic.arpa'.

Mike

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 12:44:47 EDT
From:      bjp@MITRE-BEDFORD.ARPA
To:        comp.protocols.tcp-ip
Subject:   SMTP for any UNIX on any kind of AT


Folks I need some help.  Is there anyone out there that has mil stnd
simple mail runing on any version of an AT under any version of UNIX?
If so, please let me know what versions and the vendors where you bought
it, there names addresses and phone numbers.  I need the answer by
tomorrow afternoon.

					bj Pease

PS	Sorry for the double message but I forgot to give you my
email address.  Here it is:  bjp@mitre-bedford.arpa

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 13:34:53 EDT
From:      lazear@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Vendors on MILNET

I may have missed something somewhere, but I thought MIL-NET had something
to do with MIL-itary, production systems, national defense.  I must have
been reading the glossy brochures again!  Oh, I know ... 
	Military-Industrial-Liaison-NET

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 13:40:07 EDT
From:      lazear@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Vendors on MILNET


I may have missed something somewhere, but I thought MIL-NET had something
to do with MIL-itary, production systems, national defense.  I must have
been reading the glossy brochures again!  Oh, I know ... 
	Military-Industrial-Liaison-NET

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 14:52:11 EDT
From:      lazear@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: Vendors on MILNET

Alan,
	I would indeed be interested in the details, since there are
still parts of DCA touting the eventual closing of the mail bridges
and the rehoming of hosts to their proper side.  Then there's the
issue of dual-homed hosts....  

	If DCA isn't serious about the architecture they have
advertised as the target, then we should eliminate the mail bridges
altogether, connect MILNET and ARPANET as one, and improve performance
for everyone!  Perhaps a changing of the guard at DCA has made
past work obsolete, but they need to tell both themselves and the
outside world that that is so (if indeed it is so).

	Walt

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 15:19:26 EDT
From:      dab@oliver.cray.COM (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong telnet and new line processing


In reply to William R. King's message, where he is trying to connect
to a VAX/VMS system running Wollongong.  He claims that when using
telnet from a directly connected terminal on his 4.3BSD VAX things
would work, but when he was logged into the VAX via a Bridge cs/1
terminal, all of his \r's were turned into \n, which on VMS thought
that meant 'delete a word to the left of the cursor'.  Bill changed
telnet, and belives that it is a pty problem on the VAX.

	My guess is that it is either a Bridge or a 4.3 telnetd
problem, or mayby even a combination of them. When you run telnet,
it defaults to single character input, with remote echo.  In this
mode, every character that comes in from the terminal/pty is passed
straight through.  Telnet puts the the terminal/pty into CBREAK mode,
with ECHO & CRMOD turned OFF.  This means that the terminal driver
will do no translation between \r and \n.  Hence, if a \n is showing
up at the VMS node, it must be coming from before the pty, i.e. either
from telnetd or dirctly from the Bridge box.
	Be aware that between 4.2 and 4.3, changes were made to both
telnet and telnetd to deal with the \r/\n issue.  4.2 did not conform
to the TELNET spec in this area.
	A simple test that could be done would be to write a short
program that puts the terminal into CBREAK mode, and turns off ECHO
and CRMOD, and then just dumps it's input in octal.  Run that on the
4.3 VAX when logged in from the Bridge box, and see what it sees when
you type \r.
	Then write a dummy server that does the same thing, run it on
some other TCP port, and telnet to that alternate port from the Bridge
box (assuming it will let you do that...), and see what it says a \r is.
	If you get "\n" in the first case, and "\r" or "\r\n" in
the second case, the problem is in telnetd.  If you get "\n" in
both cases, then the problem is in the Bridge box.
	If the 4.3 telnetd is not in binary mode, then "\r\n" will be
translated to "\n".  If the bridge box is sending "\r\n" when you type
"\r", then the 4.3 telnetd is where the translation is taking place.
What should be sent is "\r\0", which is the correct sequence to send
according to the TELNET spec. (If the 4.3 telnetd is in BINARY mode,
then this translation will not take place.) "\r/\n" means "move the
cursor to the begining of the next line", usually tranlated to '\n'
on UNIX machines, "\r\0" means do a "carriage return", (octal 015)
and a '\n' (not preceeded by '\r') means do a "line feed" (octal 012).

	I hope I've helped to clarify things, not confuse them even
more.
		-Dave Borman,
		Cray Research, Inc.
		dab@umn-rei-uc.arpa

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 15:57:15 EDT
From:      CASNER@VENERA.ISI.EDU (Stephen Casner)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong telnet and new line processing

The TELNET spec (RFC 854, pp. 11-12) says that the line terminator is
to be the pair of characters CR-LF (\r\n if you prefer).  I have seen
problems in both UNIX user telnet (sending just \n) and server telnet
(not interpreting \r\n properly).  This particular bit of UNIX chauvinism
seems to be rather difficult to stamp out.  The problem has been discussed
on this list more than once in the past.  It often comes up when one tries
to communicate between a UNIX machine and something else.
-------

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 16:27:24 EDT
From:      leiner@riacs.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Name of NIC (was: twg, and nic not knowing its domain name..)

Mike,

That was the reason for having ORG or NET as a top level domain.

Barry
----------

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jul 87 19:55 PDT
From:      Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: wollongong telnet and new line processing
> Unix translate the \r into a \n and sends it across the net
> to the VMS machine which promptly deletes the word GUEST. This
> makes logging in a little difficult.

> I say this because if you are connect to the Unix machine
> via a direct line everything works fine. This problem only
> occurs when you are connected via a pty. We use Bridge
> cs/1 terminal servers almost exclusivly, hence you are always
> connected to a pty and never to a direct line.

> This leads me to think that the problem lies somewhere in the
> pty driver. Anyone have any ideas?
> Bill King

We had the same problem here, but a different manifestation (couldn't
run a local editor or TELNET to a VMS system running CMU IP/TCP).

The problem occurs when you connect via TELNET to a 4.3 system and then
run any program which reads in raw mode and expects to see EXACTLY the
key the user typed.  I traced the problem to the fact that "telnetd.c"
has the following in it:

                        /*
                         * We map \r\n ==> \n, since \r\n says
                         * that we want to be in column 1 of the next
                         * printable line, and \n is the standard
                         * unix way of saying that (\r is only good
                         * if CRMOD is set, which it normally is).
                         */
                        if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') {
                                if ((ncc > 0) && ('\n' == *netip)) {
                                        netip++; ncc--;
                                        c = '\n';
                                } else {
                                        state = TS_CR;
                                }
                        }

I don't think it's right to map <CR><LF> to <LF>.  I changed it to map to <CR>
instead, and everything works just fine.  The terminal driver will map the <CR>
to <LF> when necessary and programs that think that are supposed to get a <CR>
now work fine.

My rationale was that the UNIX tty driver is set up to work with terminals
that usually send <CR> when the user hits "carriage return".  A pty works
just like a tty, so we should be sending <CR> into it.

I suppose another approach might be to say that the Bridge TELNET code is
broken and that it shouldn't be sending <CR><LF> when you type
"carriage return" but should send <CR><NUL>.  I can't fix the Bridge code,
though.

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 19:21:51 EDT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Berkeley (not Wollongong) telnet and new line processing

That one is completely Berkeley's fault!

The explanation of new line processing is presented with excruciating
clarity on pages 11-12 of RFC 854, "Telnet".

For reasons unknown to god or man, instead of fixing new line
processing between 4.2BSD and 4.3BSD, it got broken worse.  (I hope
the reason was ignorance, not independence!)

There are three "characters" which the Telnet Network Virtual Terminal
can encode:

netascii	function	what it means
chracters

<CR><LF>	newline		go to first column of next line

<CR><NUL>	carriage-	go to first column of this line
		return

<LF>		line-feed	go to same column in next line

Note that most systems only conceive of two of these, since there are
only two keys on the keyboard.

In user Telnet, you should send <CR><LF> when the user types whatever
the "doit!" key is on that system.  On a VMS system, that would be
when the user types <CR>.  On a UNIX system with "stty -nl", that
would be when the user types <CR>, although the input stream may have
returned <LF> ('\n'), depending on how raw the terminal is.  On a UNIX
system in "stty nl" state (native Teletype model 37), the <CR><LF>
gets sent when <LF> is typed.

For the VMS and UNIX "stty -nl" cases, when the user types <LF>, you
send <LF>.  Note that there is no simple way for that user to send
<CR><NUL>.  In the UNIX "stty nl" case, when the user typed <CR>, then
you would send <CR><NUL>.

Now for server Telnet.  On the VMS system, the server should type <CR>
when it sees <CR><LF> from Telnet.  It should also do so when it sees
<CR><NUL>.  (To be gracious of goofs like 4.2BSD, it should also
accept naked <CR>.)  Presuming that a UNIX server Telnet would
probably always have the psuedo-tty in "stty -nl" mode, it would
behave the same.

Both of these systems would type <NL> when they saw <NL> on the Telnet
stream. 

Similar conventions apply to output operations.  On UNIX, printf("\n")
should send <CR><LF>, and printf("\r") should send <CR><NUL>.  On VMS,
you just take the VT100 terminal stream, and stuff a <NUL> after any
naked <CR>.  (VMS allows naked <CR> or <LF> from an application
program.)

The user telnet has to sort out the incoming netascii and do the right
thing to the terminal.  (If the terminal doesn't mind a few <NUL>s,
you can probably send straight netascii.)

As always, follow the robustness principle (p.13 RFC 793, "TCP"):

	be conservative in what you do, be liberal in what you
	accept from others

In Telnet, this poses several corollaries:

1. Generate only legal netascii on a Telnet stream

2. The noraml netascii sequence should be <CR><LF>

3. Accept all three netascii sequences on input from Telnet streams

4. Accept degenerate netascii (<CR> not folloed by <NUL> or <LF>) to
cope with broken software

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 20:23:50 EDT
From:      tomlin@hc.DSPO.GOV (Bob Tomlinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for VAX/VMS  (Really NRC's Fusion TCP/IP)

in article <670@julian.UWO.CDN>, peter@julian.UUCP says:
>
>>	You might also tell DEC about it, since they sell TWG software
>>for VMS as the official VAX?VMS TCP/IP product.
> 
> In my last conversation with Digital about this, they said that Digital
> had had  so much support trouble with The Wollongong Group that they were now
> recommending the Fusion product for TCP/IP under VMS.
>    I suppose that this might be just a Canadian phenomenon.

I don't think it's just a Canadian phenomenon.  I've heard similar things here.
We're using Fusion TCP/IP for VMS here.  We mainly use it to communicate
with 4.3bsd VAXs and Suns.  My main complaint with them now is they don't
have a domain name system resolver.  Does anybody else out there use Fusion
TCP/IP on VMS?

bob
-- 
Bob Tomlinson -- tomlin@hc.dspo.gov  --  (505) 667-8495
Los Alamos National Laboratory  --  MEE-10/Data Systems

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 22:55:00 EDT
From:      KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso)
To:        comp.protocols.tcp-ip
Subject:   Re: wollongong telnet and new line processing

> Unix translate the \r into a \n and sends it across the net
> to the VMS machine which promptly deletes the word GUEST. This
> makes logging in a little difficult.
 
> I say this because if you are connect to the Unix machine
> via a direct line everything works fine. This problem only
> occurs when you are connected via a pty. We use Bridge
> cs/1 terminal servers almost exclusivly, hence you are always
> connected to a pty and never to a direct line.
 
> This leads me to think that the problem lies somewhere in the
> pty driver. Anyone have any ideas?
> Bill King

We had the same problem here, but a different manifestation (couldn't
run a local editor or TELNET to a VMS system running CMU IP/TCP).

The problem occurs when you connect via TELNET to a 4.3 system and then
run any program which reads in raw mode and expects to see EXACTLY the
key the user typed.  I traced the problem to the fact that "telnetd.c"
has the following in it:

                        /*
                         * We map \r\n ==> \n, since \r\n says
                         * that we want to be in column 1 of the next
                         * printable line, and \n is the standard
                         * unix way of saying that (\r is only good
                         * if CRMOD is set, which it normally is).
                         */
                        if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') {
                                if ((ncc > 0) && ('\n' == *netip)) {
                                        netip++; ncc--;
                                        c = '\n';
                                } else {
                                        state = TS_CR;
                                }
                        }

I don't think it's right to map <CR><LF> to <LF>.  I changed it to map to <CR>
instead, and everything works just fine.  The terminal driver will map the <CR>
to <LF> when necessary and programs that think that are supposed to get a <CR>
now work fine.

My rationale was that the UNIX tty driver is set up to work with terminals
that usually send <CR> when the user hits "carriage return".  A pty works
just like a tty, so we should be sending <CR> into it.

I suppose another approach might be to say that the Bridge TELNET code is
broken and that it shouldn't be sending <CR><LF> when you type
"carriage return" but should send <CR><NUL>.  I can't fix the Bridge code,
though.

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Jul-87 23:37:52 EDT
From:      gnu@hoptoad.uucp (John Gilmore)
To:        comp.protocols.tcp-ip
Subject:   Re: PD TCP/IP requests

charny@GATEWAY.MITRE.ORG (M. Charny) wrote:
> Subject: Re: PD TCP/IP requests
> 
> MITRE is not in the business of distributing or maintaining software.  Devices
> and software created by MITRE are prototypes created for particular sponsors.
> The programs are available to the outside world according to the conditions
> and procedures listed below.
> 	-- they agree to the four conditions listed below 
> 		(please explicitly list the conditions in the letter).
> 		i.  The MITRE TCP/IP source files will not be passed on to
> 			any third party.

How can this software be called "public domain" if it can't be passed on?

Also, I am interested in who actually owns this software.  If it was
written on contract for the government, it is owned by the government,
as a work for hire.  Since the government cannot copyright things it owns,
(this is explicit in the Copyright Act), this would mean that the code is
in the public domain, and MITRE has no right to put these kind of restrictions
on it.

I presume that whoever contracted to have MITRE do this work is on the net.
Or their DARPA sponsor is on the net.  Can you clarify the ownership of the
code and the origin of these restrictions?
-- 
{dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu	     gnu@postgres.berkeley.edu
Alt.all: the alternative radio of the Usenet.

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 01:31:48 EDT
From:      lear@ARAMIS.RUTGERS.EDU (eliot lear)
To:        comp.protocols.tcp-ip
Subject:   CRLF stuff


There is (was?) a definite bug Sun 3.2 in.telnetd where it would send
LF when one pressed CR.  The bug involved going into state TS_CR (just
seen a CR) and then dropping the CR on the floor if the next character
was LF.

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 06:13:32 EDT
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: TWG on MILNET?

I suppose the reason the TWG will be homed on the Milnet instead
of the Arpanet is that the sponsor suggested the Milnet.  Remember that
someone in the government pay for every connection to the Milnet or
the Arpanet.  The Arpanet cost me about $3500 per port connection per month.
I am not sure what the Milnet connections cost.

Yes, there is a fuzzing of the lines between Milnet and Arpanet.  As
turnover at the DDN PMO more and more of the history of the Arpanet
and the reason for the split into the Milnet and Arpanet is lost, and
therefore the definition of why each exists is lost.  A strong tendency
exists already to consider them as equal nets, with little distinction
between them or little appreciation of what the experimental Arpanet
can do for the operational Milnet.

dennis
-------

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 06:33:56 EDT
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Name of NIC (was: twg, and nic not knowing its domain na...

Mike, who you gonna argue with?  It seems to me that you should just
write the memo to the Col and say here we what we are going to do and
when and why.  No one else cares about what the NIC is called.

I will help you with the Col if you want it.

dennis
-------

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 09:08:20 EDT
From:      mel1@houxa.UUCP (M.HAAS)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

Would someone please post a summary of reasons why use of Streams is
an advantage.  Is this just another sales-hype buzzword?  or is there
a reason Streams is better?  than sockets?  than psudo-sockets? or
select?  Does the end user see any advantage?  faster response?  less
CPU waste?  what?  Does anyone have some before & after figures on
drivers that were converted to Streams?  Please share them with us.
  Thanks,
     Mel Haas  ,  odyssey!mel

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 87 12:11:42 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
Cc:        Andy Malis <malis@CC5.BBN.COM>, tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: Internet Uselessness
Mike,

Your impression is correct: many X.25 networks (e.g. TELENET) set
up a path at call setup time and then force all packets along
that fixed path, just using the VC number for identification.

Your inference is also correct: in BBNCC networks, the same
underlying packet format (and dynamic adaptive routing) is used
for both AHIP and X.25 traffic.

If you are interested in the workings of the backbone subnet, you
might like to read my RFC 979.  It is the functional
specification for the PSN's new End-to-End protocol, which is
being implemented in PSN 7.0 (PSN 6.0 is now running in the
subnet).  My statement above concerning packet formats and
routing is true for both the existing and the new EEs.

Cheers,
Andy
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 09:37:32 EDT
From:      dpowles@CCD.BBN.COM ("Drew M. Powles")
To:        comp.protocols.tcp-ip
Subject:   RLP

Does anyone out there have an implementation of, or at least any
experience with, the Resource Location Protocol, as described in RFC
887, dated December 1983? 

thanks for the help. 

Drew M. Powles 
BBN Communication 
dpowles@ccd.bbn.com

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 87 09:37:32 EDT
From:      "Drew M. Powles" <dpowles@ccd.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        dpowles@ccd.bbn.com
Subject:   RLP
Does anyone out there have an implementation of, or at least any
experience with, the Resource Location Protocol, as described in RFC
887, dated December 1983? 

thanks for the help. 

Drew M. Powles 
BBN Communication 
dpowles@ccd.bbn.com

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 87 05:37:41 GMT
From:      ejnorman@unix.macc.wisc.edu  (Eric Norman)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Berkeley (not Wollongong) telnet and new line processing
John A. Shriver explains:
  
> In user Telnet, you should send <CR><LF> when the user types whatever
> the "doit!" key is on that system.  On a VMS system, that would be

What has always bothered me about RFC 854, et al. is that there is a
clear statement of the physical effect that CR's and LF's have on the
printer of a NVT.  However, I can see no clear statement that the
sequence CR-LF means "it's your turn now".  This is muddied by the
fact that there is a "go ahead" signal, but it's not necessary.

I look at it this way, which seems to agree with what John suggests.
I have a keyboard here that I push keys on.  When I push a key, one
or more characters are sent off to some computer over some wires.
When I push the key labelled "return", something happens so that I
get a response from the computer on the other end.  If back-to-back
NVT's are spliced into the wire between my keyboard and that computer,
I would hope that that behavior doesn't change.

Eric Norman
Internet:     ejnorman@unix2.macc.wisc.edu
UUCP:         ...{allegra,ihnp4,seismo}!uwvax!ejnorman
Life:         Detroit!Alexandria!Omaha!Indianapolis!Madison!Hyde
  
"Forest fires prevent bears."		-- bumper sticker
--
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 09:56:28 EDT
From:      dpowles@CCD.BBN.COM ("Drew M. Powles")
To:        comp.protocols.tcp-ip
Subject:   SMTP question

This may sound like a silly question, but believe me, I have a need.  

In going through the SMTP spec, there doesn't seem to be any provision
for embedding full octets in the body of the message, only seven bit
ascii.  Is this an artificial limitation?  What if I want to use
special characters embedded in my text?  TCP does provide an eight-bit
byte interface.  Does anyone have any thoughts or experiences along
these lines they could share with me?

thanks.

Drew M. Powles
BBN Communications
dpowles@ccd.bbn.com

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 87 09:56:28 EDT
From:      "Drew M. Powles" <dpowles@ccd.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        dpowles@ccd.bbn.com
Subject:   SMTP question
This may sound like a silly question, but believe me, I have a need.  

In going through the SMTP spec, there doesn't seem to be any provision
for embedding full octets in the body of the message, only seven bit
ascii.  Is this an artificial limitation?  What if I want to use
special characters embedded in my text?  TCP does provide an eight-bit
byte interface.  Does anyone have any thoughts or experiences along
these lines they could share with me?

thanks.

Drew M. Powles
BBN Communications
dpowles@ccd.bbn.com


-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 10:03:10 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Uselessness

Andy--

I certainly did NOT mean to imply that we aren't doing good engineering,
merely that a bit more ruthlessness in extreme situations (which I
attempted to euphemize as "clever engineering") might be in order.
No intention whatsoever to minimize the efforts of the BBN troops
who keep the subnet going, whom I don't recall picking on since '71,
when the IMP's support for halfduplex interfaces wasn't as advertized.
(Horror Story Number Five involved TENEX, of course, but that's not
the subnet.)  Will be looking forward to the forthcoming congestion
control stuff.

A quibble over "addressing information": any packet that contains the
destination PSN number is addressed enough for me.  My impression was
(indeed, still is), though, that many/most X.25 subnets use the interface
format with just the VC number for packets in flight.  I'd be relieved
to learn I'm wrong in general, and am delighted to infer from your msg
that that isn't how it's done on our backbone.

   cheers, map
-------

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1987 10:03:10 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Andy Malis <malis@CC5.BBN.COM>
Cc:        PADLIPSKY@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Internet Uselessness
Andy--

I certainly did NOT mean to imply that we aren't doing good engineering,
merely that a bit more ruthlessness in extreme situations (which I
attempted to euphemize as "clever engineering") might be in order.
No intention whatsoever to minimize the efforts of the BBN troops
who keep the subnet going, whom I don't recall picking on since '71,
when the IMP's support for halfduplex interfaces wasn't as advertized.
(Horror Story Number Five involved TENEX, of course, but that's not
the subnet.)  Will be looking forward to the forthcoming congestion
control stuff.

A quibble over "addressing information": any packet that contains the
destination PSN number is addressed enough for me.  My impression was
(indeed, still is), though, that many/most X.25 subnets use the interface
format with just the VC number for packets in flight.  I'd be relieved
to learn I'm wrong in general, and am delighted to infer from your msg
that that isn't how it's done on our backbone.

   cheers, map
-------
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 12:38:24 EDT
From:      malis@CC5.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Uselessness

Mike,

Your impression is correct: many X.25 networks (e.g. TELENET) set
up a path at call setup time and then force all packets along
that fixed path, just using the VC number for identification.

Your inference is also correct: in BBNCC networks, the same
underlying packet format (and dynamic adaptive routing) is used
for both AHIP and X.25 traffic.

If you are interested in the workings of the backbone subnet, you
might like to read my RFC 979.  It is the functional
specification for the PSN's new End-to-End protocol, which is
being implemented in PSN 7.0 (PSN 6.0 is now running in the
subnet).  My statement above concerning packet formats and
routing is true for both the existing and the new EEs.

Cheers,
Andy

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 12:38:47 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  SMTP for any UNIX on any kind of AT

IBM has an implementation of POP 2 for the IBM PC.  It's part of their
TCP/IP support for the PC.  This is probably as close as you will
come to SMTP for a PC.  

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 12:43:12 EDT
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Vendors on MILNET

Actually, the Milnet and Arpanet used to be the same net.  They were
split some time ago into the Arpanet, mostly university researchers, and
the Milnet, mostly government agencies, not all of which were military.
E.g., the DOE national labs are on the milnet.  Not all those on the
Milnet are operational folks, although most are.  There are still
a lot of research related folks on the Milnet.  As I said earlier, it
it no longer clear, except for sponsorship, who get put where.

dennis
-------

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 13:26:36 EDT
From:      braden@BRADEN.ISI.EDU (Bob Braden)
To:        comp.protocols.tcp-ip
Subject:   Re:  4.3 IP multicast



	From YAKOV@IBM.COM Mon Jul 20 22:32:50 1987
	Posted-Date: 20 July 1987, 09:53:11 EDT
	Received-Date: Mon, 20 Jul 87 22:32:38 PDT
	Received: from ibm.com by braden.isi.edu (5.54/5.51)
		id AA01617; Mon, 20 Jul 87 22:32:38 PDT
	Date: 20 July 1987, 09:53:11 EDT
	From: Jacob Rekhter <YAKOV@ibm.com>
	To: braden@braden.isi.edu
	Message-Id: <072087.095311.yakov@ibm.com>
	Subject: 4.3 IP multicast
	Status: R
	
	
	Recently you mentioned, that 4.3 BSD IP multicast is available.
	How can I get it ?
	Jacob Rekhter (YAKOV @ IBM.COM)

	

The IP Multicasting extensions described in RFC988 have been implemented
for 4.3bsd Unix by Karen Lam of BBN Labs.  This software is available
for experimental purposes to sites that have 4.3bsd source code.
In addition to full support for the RFC988 extensions, the software
includes a prototype "multicast agent" demon which enables a Unix host
to act as an inter-network relay for IP multicast packets, and a version
of Berkeley's "rwhod" that uses multicast instead of broadcast datagrams.

To obtain the software, a site will have to sign a licence with BBN
certifying that they possess a 4.3bsd source license.  The software
is distributed on a 1600bpi tar tape and comes with printed installation
and usage notes.  Interested parties should contact Craig Partridge
(craig@bbn.com or craig@nnsc.nsf.net).

It is important to note that the internetwork multicasting protocols are
still under development and subject to change.  Sites that obtain the
software are urged to contact Steve Deering at Stanford University
(deering@pescadero.stanford.edu) who maintains a mailing list for bug
reports, updates, and discussion of changes to the multicast software
and protocols.

	
   Bob Braden

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 14:07:23 EDT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Uselessness


>As a whole, I think the internet community has been doing "clever
>engineering" for quite a number of years now.  However, there
>comes a time when offered load just overwhelms the resources
>devoted to the task.  We are very close to that point on the
>ARPANET, even though we just made the routing algorithm more
>"clever" and added another transcontinental trunk.

COMMENT: "Clever Engineering" - The ARPANET has been around for 
17 Years and there is still a need for clever engineering;
that's discouraging.

>We are currently in the process of implementing congestion
>control in the PSNs.  This should optimize the total available
>throughput of the network (at the expense of backing flows into
>source hosts if necessary).

COMMENT: With about a hundred different flavors of TCP/IP, some (many?) 
of which are network-hostile, the subscriber community is forcing the 
ARPANET designers to defend themselves.

>Finally, the X.25 spec really says nothing about what goes on in
>the subnet, it is just an interface spec between a DTE and its
>DCE.  Internally, the PSNs use virtual circuits to support both
>AHIP (1822) and X.25 traffic while using good old dynamic
>adaptive routing to get the packets between the endpoint PSNs.
>Internally, neither AHIP nor X.25 data packets contain full
>addressing information, just the destination PSN number and a
>connection identifier at that PSN.  So I guess you might say that
>we "do it right".

COMMENT: I didn't say it, Andy Malis said it: "...PSNs use virtual
circuits ... packets [DO NOT] contain full addressing information."
Then why are we flogging the network 40 octets of header per packet?

Isn't it time to swallow our embarrassment and admit that while
TCP/IP looks good on paper, in the reality of limited bandwidth and
unstable network delays, TCP/IP is, in fact, a Bad Idea?  The subscriber
and network communities need to work together and come up with a scheme
that doesn't hammer the network to its knees when something goes wrong.
The Commercial/PTT networks can do it, why can't we?  

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jul 87 16:51:12 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        "H. Craig McKee" <mckee@MITRE.ARPA>
Cc:        Andy Malis <malis@CC5.BBN.COM>, PADLIPSKY@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Internet Uselessness
Craig,

I would like to respond to a couple of points in your message.

On the need for "clever engineering", and defending the ARPANET:
for all of its sophistication, the PSN's dynamic routing
algorithm was originally designed for, and worked very well in,
an environment where the offered load did not come close to
congesting the network's resources.  This is no longer the case,
with network subnet congestion as the predictable result.  The
recent changes in routing are actually slight modifications to
one part of the algorithm, to try to prevent routing oscillations
as a result of congested paths and to make the cross-country
satellite link more attractive when the land lines start
congesting.

As Steve Cohn said in a previous message, a more detailed
description of the change, and its effects, will be forthcoming.

Congestion control will further help the network in these days of
plentiful load and scarce resources.

I really don't see what we are doing as defending ourselves from
network-hostile hosts; rather, we are trying to allocate scarce
resources as fairly and evenly as possible, and trying to keep
the network from going past the point where additional load would
cause the network's total throughput to start degrading.  Of
course, that doesn't mean that there aren't "hostile" hosts out
there.

On 40 octets of header per packets: I was referring to the
internals of the ARPANET and MILNET subnets when I was discussing
packet headers and such.  However, they are only two networks on
an internet of over 100 networks now.  I am not a TCP/IP
implementer so I won't get into whether any of the 40 octets can
be squeezed out; you just have to realize that the environment
TCP/IP runs in is nothing like that of commercial and PTT
networks.  X.25 does internetting (X.75) using fixed routes
though transit networks and X.75 gateways without an end-to-end
transport layer like TCP, and is nowhere as reliable and
survivable as the TCP/IP internet.  But you have to pay for this
by using large datagram headers and end-to-end retransmissions.

I do agree that some of the assumptions that were made during the
TCP/IP design days (such as a richly configured backbone network)
may no longer be valid.  It may be time to revisit TCP/IP's
design, especially in light of the OSI protocol suite, just as
long as we keep in mind the overall requirements of the internet.

Andy
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 17:28:53 EDT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Uselessness

Craig,

I would like to respond to a couple of points in your message.

On the need for "clever engineering", and defending the ARPANET:
for all of its sophistication, the PSN's dynamic routing
algorithm was originally designed for, and worked very well in,
an environment where the offered load did not come close to
congesting the network's resources.  This is no longer the case,
with network subnet congestion as the predictable result.  The
recent changes in routing are actually slight modifications to
one part of the algorithm, to try to prevent routing oscillations
as a result of congested paths and to make the cross-country
satellite link more attractive when the land lines start
congesting.

As Steve Cohn said in a previous message, a more detailed
description of the change, and its effects, will be forthcoming.

Congestion control will further help the network in these days of
plentiful load and scarce resources.

I really don't see what we are doing as defending ourselves from
network-hostile hosts; rather, we are trying to allocate scarce
resources as fairly and evenly as possible, and trying to keep
the network from going past the point where additional load would
cause the network's total throughput to start degrading.  Of
course, that doesn't mean that there aren't "hostile" hosts out
there.

On 40 octets of header per packets: I was referring to the
internals of the ARPANET and MILNET subnets when I was discussing
packet headers and such.  However, they are only two networks on
an internet of over 100 networks now.  I am not a TCP/IP
implementer so I won't get into whether any of the 40 octets can
be squeezed out; you just have to realize that the environment
TCP/IP runs in is nothing like that of commercial and PTT
networks.  X.25 does internetting (X.75) using fixed routes
though transit networks and X.75 gateways without an end-to-end
transport layer like TCP, and is nowhere as reliable and
survivable as the TCP/IP internet.  But you have to pay for this
by using large datagram headers and end-to-end retransmissions.

I do agree that some of the assumptions that were made during the
TCP/IP design days (such as a richly configured backbone network)
may no longer be valid.  It may be time to revisit TCP/IP's
design, especially in light of the OSI protocol suite, just as
long as we keep in mind the overall requirements of the internet.

Andy

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 22:03:44 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Wollongong telnet and new line processing

Steve,

Well, the annual raucus caucus over the TELNET new-line convention has
come around again, exactly a year after the previous one, which itself
was the latest in the annual series. last year it was Ford Research
squawking that Wollongongware did not love fuzzballs. Subsequently,
the Wollongongbunch responded to the complaint and fixed the problem.
The present instance suggests the gongfermers should be called. You
may look up that interesting word in a dictionary.

Dave

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 23:16:56 EDT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re:  SMTP for any UNIX on any kind of AT


    IBM has an implementation of POP 2 for the IBM PC.  It's part of their
    TCP/IP support for the PC.  This is probably as close as you will
    come to SMTP for a PC.  

FTP Software has SMTP client and server in the PC/TCP (DOS) package.  I don't
know a great deal about the various Xenix offerings, but I don't think any
of those currently available has SMTP.

jbvb

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Jul-87 23:34:34 EDT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Streams TCP/IP

Spider Systems, Edinburgh, U.K. lists one in the current printing of the
Vandors Guide, and I believe it is available in source form.  Beyond that,
I know nothing about it.

jbvb

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 07:18:21 EDT
From:      espo@bpa.BELL-ATL.COM (Bob Esposito)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

In article <725@hjuxa.UUCP> kp@hjuxa.UUCP (Karen Paszamant) writes:
>
>Does anyone know what vendors have a System V Release 3.0
>streams based tcp/ip product?  The only vendors I have found
>so far are Lachman Assoc. & Wollongong.  There must be others.
>
>Thanks, in advance


	Uniq Digital Technologies in Batavia, IL. does have a Streams
	based TCP/IP product for System V Release 3.0  They advertise
	being the leading supplier for AT&T System V.3 with RFS for
	Digital Equipment Corp. processors.


-- 
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===
 Bob Esposito,  Bell of Pennsylvania - espo@bpa.bell-atl.com - (215) 466-6831
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 08:27:01 EDT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: Berkeley (not Wollongong) telnet and new line processing

John,

Your elucidation of the handling of line-termination characters
in TELNET is the best I've seen in a long time; congratulations!

On the other hand, it's unfortunate that after so many years it
still needs to be explained!

TELNET's careful handling of the various line-termination
possibilities is one of the "great compromises" of the relatively
early days of the ARPANET (the bit-serial 1822 interface,
accomodating computers with the bewildering array of word sizes
found in late '60s - early '70s machines, being another).  It
arose through the efforts of the IBM EBCDIC-newline-physical-
half-duplex, Multics LF-is-newline (from which UNIX got its idea
of newline) and various DEC (and other) you-CR-and-I'll-echo-the-LF
camps to develop something that would work for everyone and that
was easily converted at each end of the connection.  That
different systems STILL have different conventions (UNIX vs VMS,
for example) after all this time underscores the importance of
the TELNET ASCII compromise -- as well as the importance of
implementing it correctly.

Thanks, John, for your explanation.

Regards,
 Ken Pogran

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jul 87  8:27:01 EDT
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        jas@monk.proteon.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Berkeley (not Wollongong) telnet and new line processing
John,

Your elucidation of the handling of line-termination characters
in TELNET is the best I've seen in a long time; congratulations!

On the other hand, it's unfortunate that after so many years it
still needs to be explained!

TELNET's careful handling of the various line-termination
possibilities is one of the "great compromises" of the relatively
early days of the ARPANET (the bit-serial 1822 interface,
accomodating computers with the bewildering array of word sizes
found in late '60s - early '70s machines, being another).  It
arose through the efforts of the IBM EBCDIC-newline-physical-
half-duplex, Multics LF-is-newline (from which UNIX got its idea
of newline) and various DEC (and other) you-CR-and-I'll-echo-the-LF
camps to develop something that would work for everyone and that
was easily converted at each end of the connection.  That
different systems STILL have different conventions (UNIX vs VMS,
for example) after all this time underscores the importance of
the TELNET ASCII compromise -- as well as the importance of
implementing it correctly.

Thanks, John, for your explanation.

Regards,
 Ken Pogran
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 08:31:35 EDT
From:      jjensen@atlas.UUCP (Jim Jensen)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong telnet and new line processing


in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says:
> 
> I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS
> system using Wollongong telnet and have discovered an interesting
> problem. Unix uses \n as the line terminator,
>[deleted about sending a \r to VMS]
> Unix translate the \r into a \n and sends it across the net
> [problems this causes on VMS deleted]
> I've modified telnet to send a \r instead of a \n for the line
> terminator. Although I think this is only a work around.
> 
> I say this because if you are connect to the Unix machine
> via a direct line everything works fine. This problem only
> occurs when you are connected via a pty. We use Bridge
> cs/1 terminal servers almost exclusivly, hence you are always
> connected to a pty and never to a direct line. 
> 

(this is my first posting so I dont know if I am doing this right)

I just finished writing telnet for MPX (Gould's real time OS), and ran into 
the same problem.  The bridge box sends a \r\n which is the specifed in the
telnet rfc as the end of line character. which the unix telnet server turns
into a \n.

on telnet 4.2 the  telnet task, converts this back to \r\n 
which the VMS(or MPX)server converts back to a \r and everything works.

4.3 leaves it as a \n, which seems to me to be a clear violation of the 
protocol.  The rfc SAYS that \r\n is the end of line character, not \n.
Thats what protocols are for; To take care of differences between machines.
When a protocol is not followed problems like this happen.

I asked one of our unix people about it, and he said that  
BSD did it on purpose, and it is in telnet. I was unable to convince
him it was a mistake, so he would not change it.  that is until some people
in our unix group tried to use a bridge box. Thus:

 the latest patch to Gould Unix has a telnetd which has a variable that can be
set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes 
the problem.

I am not a unix person, so I may have gotten something wrong about unix, but
I don't think so.
                                              Jim Jensen
					      Gould inc. CSD 
					      6901 West Sunrise Boulevard
					      Ft. Lauderdale Fl 33313-4499
					      (305) 587-2900

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 08:39:18 EDT
From:      jjensen@atlas.UUCP (Jim Jensen)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong telnet and new line processing

in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says:
> 
> I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS
> system using Wollongong telnet and have discovered an interesting
> problem. Unix uses \n as the line terminator,
>[deleted about sending a \r to VMS]
> Unix translate the \r into a \n and sends it across the net
> [problems this causes on VMS deleted]
> I've modified telnet to send a \r instead of a \n for the line
> terminator. Although I think this is only a work around.
> 
> I say this because if you are connect to the Unix machine
> via a direct line everything works fine. This problem only
> occurs when you are connected via a pty. We use Bridge
> cs/1 terminal servers almost exclusivly, hence you are always
> connected to a pty and never to a direct line. 
> 

(this is my first posting so I dont know if I am doing this right)

I just finished writing telnet for MPX (Gould's real time OS), and ran into 
the same problem.  The bridge box sends a \r\n which is the specifed in the
telnet rfc as the end of line character. which the unix telnet server turns
into a \n.

on telnet 4.2 the  telnet task, converts this back to \r\n 
which the VMS(or MPX)server converts back to a \r and everything works.

4.3 leaves it as a \n, which seems to me to be a clear violation of the 
protocol.  The rfc SAYS that \r\n is the end of line character, not \n.
Thats what protocols are for; To take care of differences between machines.
When a protocol is not followed problems like this happen.

I asked one of our unix people about it, and he said that  
BSD did it on purpose, and it is in telnet. I was unable to convince
him it was a mistake, so he would not change it.  that is until some people
in our unix group tried to use a bridge box. Thus:

 the latest patch to Gould Unix has a telnetd which has a variable that can be
set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes 
the problem.

I am not a unix person, so I may have gotten something wrong about unix, but
I don't think so.
                                              Jim Jensen
					      Gould inc. CSD 
					      6901 West Sunrise Boulevard
					      Ft. Lauderdale Fl 33313-4499
					      (305) 587-2900

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 08:56:37 EDT
From:      jjensen@atlas.UUCP (Jim Jensen)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong telnet and new line processing



in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says:
> 
> I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS
> system using Wollongong telnet and have discovered an interesting
> problem. Unix uses \n as the line terminator,
>[deleted about sending a \r to VMS]
> Unix translate the \r into a \n and sends it across the net
> [problems this causes on VMS deleted]
> I've modified telnet to send a \r instead of a \n for the line
> terminator. Although I think this is only a work around.
> 
> I say this because if you are connect to the Unix machine
> via a direct line everything works fine. This problem only
> occurs when you are connected via a pty. We use Bridge
> cs/1 terminal servers almost exclusivly, hence you are always
> connected to a pty and never to a direct line. 
> 

(this is my first posting so I dont know if I am doing this right)

I just finished writing telnet for MPX (Gould's real time OS), and ran into 
the same problem.  The bridge box sends a \r\n which is the specifed in the
telnet rfc as the end of line character. which the unix telnet server turns
into a \n.

on telnet 4.2 the  telnet task, converts this back to \r\n 
which the VMS(or MPX)server converts back to a \r and everything works.

4.3 leaves it as a \n, which seems to me to be a clear violation of the 
protocol.  The rfc SAYS that \r\n is the end of line character, not \n.
Thats what protocols are for; To take care of differences between machines.
When a protocol is not followed problems like this happen.

I asked one of our unix people about it, and he said that  
BSD did it on purpose, and it is in telnet. I was unable to convince
him it was a mistake, so he would not change it.  that is until some people
in our unix group tried to use a bridge box. Thus:

 the latest patch to Gould Unix has a telnetd which has a variable that can be
set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes 
the problem.

I am not a unix person, so I may have gotten something wrong about unix, but
I don't think so.
                                              Jim Jensen
					      Gould inc. CSD 
					      6901 West Sunrise Boulevard

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 10:28:45 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Uselessness

H. Craig--

Just to show the unbelievers that there are some windmills even I
won't bother to lance, I'll merely answer your final rhetorical
question ("The Commercial/PTT networks can do it, why can't we?"):
As I understand the "it" John and Andy and I were talking about,
it's dealing with presented loads greater than a system was designed
to deal with; if you really think the PTTs know how to get five pounds
of bits in a two-pound sack, I hope you'll share your knowledge with us
all.  In other words, if it's physically impossible, even we can't
do it--but neither can They....

It would be too Zen to get into the subtleties of the flavor of
pie in the sky vs. the taste of bread in the mouth, but I would
feel myself remiss if I didn't mention that I've been aware of
pricing as a resource-demand regulator since my CTSS days, where
Corby told me it was already known for years to the phone company;
so I'd suggest that if the PTTs aren't groaning under their presented
loads (and for all I know they are but just don't talk about it in
public) it's because they have extra-protocol ways of limiting
the loads.  And, for that matter, if 40-byte headers bother you,
how about you be the one who finally does the exercise of totalling
up the sizes of the Network (actual), Network ("connectionless" [a/k/a
IP], Transport, Session, Presentation, Application, and Management
(times 5 or 6) "PDUs": after all, another good way of keeping the
loads down is to make things so barococo that nobody can fabricate
a load to present, right?

   pro forma cheers, map

P.S. Andy's reply to me, my reply to it, and his reply to my reply should
cast some light on the flavor of virtual circuits we were talking about
at the subnet processor to subnet processor level; sorry, I don't think
you can rightly infer that IMPs/PSNs "are" X.25 node to node.  Indeed,
the fundamental problem of the Internet in one sense is that there is
not and cannot be A node to node protocol at the subnet level, since
the subnet level is by definition hetereogenous.  Andy is adressing
the/a backbone subnet, which contrary to its original design parameters
is now dealing with a multiplicity of (to it) ancillary subnets; X.25
on the other limb is offering some (by spec) no more than 56.2 kb/s
"trunks", take 'em or leave 'em.  It's like comparing apples to
orange pits (or pips, if John Laws is still tuned in) to imagine that
Arpanet and "the PTTs" are interchangeable.  Try hooking say a 10-meg
Ethernet up to an X.25 PSN: you've either got a 56.2 bottleneck
or you're building some sort of milking machine and paying for
multiple X.25 ports even if your Hosts are "doing" X.25 as their
end-to-end/"Transport" protocol, but if the Hosts are doing the
ISO Stack, you've the same Gateway bashing problems as in the
Internet--with, almost certainly, a far less flexible/responsive
"backbone"....
-------

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1987 10:28:45 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        H. Craig McKee <mckee@MITRE.ARPA>
Cc:        Andy Malis <malis@CC5.BBN.COM>, PADLIPSKY@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Internet Uselessness
H. Craig--

Just to show the unbelievers that there are some windmills even I
won't bother to lance, I'll merely answer your final rhetorical
question ("The Commercial/PTT networks can do it, why can't we?"):
As I understand the "it" John and Andy and I were talking about,
it's dealing with presented loads greater than a system was designed
to deal with; if you really think the PTTs know how to get five pounds
of bits in a two-pound sack, I hope you'll share your knowledge with us
all.  In other words, if it's physically impossible, even we can't
do it--but neither can They....

It would be too Zen to get into the subtleties of the flavor of
pie in the sky vs. the taste of bread in the mouth, but I would
feel myself remiss if I didn't mention that I've been aware of
pricing as a resource-demand regulator since my CTSS days, where
Corby told me it was already known for years to the phone company;
so I'd suggest that if the PTTs aren't groaning under their presented
loads (and for all I know they are but just don't talk about it in
public) it's because they have extra-protocol ways of limiting
the loads.  And, for that matter, if 40-byte headers bother you,
how about you be the one who finally does the exercise of totalling
up the sizes of the Network (actual), Network ("connectionless" [a/k/a
IP], Transport, Session, Presentation, Application, and Management
(times 5 or 6) "PDUs": after all, another good way of keeping the
loads down is to make things so barococo that nobody can fabricate
a load to present, right?

   pro forma cheers, map

P.S. Andy's reply to me, my reply to it, and his reply to my reply should
cast some light on the flavor of virtual circuits we were talking about
at the subnet processor to subnet processor level; sorry, I don't think
you can rightly infer that IMPs/PSNs "are" X.25 node to node.  Indeed,
the fundamental problem of the Internet in one sense is that there is
not and cannot be A node to node protocol at the subnet level, since
the subnet level is by definition hetereogenous.  Andy is adressing
the/a backbone subnet, which contrary to its original design parameters
is now dealing with a multiplicity of (to it) ancillary subnets; X.25
on the other limb is offering some (by spec) no more than 56.2 kb/s
"trunks", take 'em or leave 'em.  It's like comparing apples to
orange pits (or pips, if John Laws is still tuned in) to imagine that
Arpanet and "the PTTs" are interchangeable.  Try hooking say a 10-meg
Ethernet up to an X.25 PSN: you've either got a 56.2 bottleneck
or you're building some sort of milking machine and paying for
multiple X.25 ports even if your Hosts are "doing" X.25 as their
end-to-end/"Transport" protocol, but if the Hosts are doing the
ISO Stack, you've the same Gateway bashing problems as in the
Internet--with, almost certainly, a far less flexible/responsive
"backbone"....
-------
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 11:35:10 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Name of NIC (was: twg, and nic not knowing its domain name..)

Watch out or they'll make the name of the hosts NET.INFO.CTR as you suggested.

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 11:49:41 EDT
From:      news@uniq.UUCP (Usenet Administration)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

In article <725@hjuxa.UUCP>, kp@hjuxa.UUCP (Karen Paszamant) writes:
> Does anyone know what vendors have a System V Release 3.0
> streams based tcp/ip product?

Uniq Digital Technologies supports UNIX System V Release 3 TCP/IP
for VAX processors.  The product, called Passage, is available in
binary or source form.  The next release of Passage will be Streams
based.  That release is expected within approximately 30 days.

Contact Trish Halleen on 1-800-DEC-UNIX for more information about
Passage or Uniq's port of System V Release 3 to VAX processors.
--
	Uniq Digital Technologies
	28 South Water Street
	Batavia, Illinois  60510

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 11:54:27 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   RE: Wollongong TCP/IP for VAX/VMS

I hope that Dave's arrival at Wollongong will certainly help the
situation there.  It seems to have gotten much better already.
However several assertions he made are false.  2.3 will make VAX's
unusable under certain instances (they don't crash, they just don't
do anything until you correct the network problem).

As for the support statement, in the past I have directly called
Woolongong with support problems and gotten the eternal run-around.

-Ron

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 11:58:20 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  TWG questions

Dbridge in Version 2 of the code is abysmal.  I don't know if it is
fixed in 3.0 since I now have a real IP path between the two sites.
It would be nice if Woolongong would take the effort of reversing this
product (allowing DECNET to flow through their IP paths) but it probalby
isn't an easy modification.

-Ron

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 13:55:19 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: PD TCP/IP requests

With Universities at least, ownership of code funded by the government
depends upon the provisions of the grant.  If the grant was a contract
that specified production of software as a deliverable, then it is
work for hire, and the code is owned by the government, or required to
be PD, or something like that.  However if the grant called for
research, and the code was in effect a sideeffect of the research,
then all agencies that I know interpret that the code was not the
thing that they were contracting for, and the University owns it.  Few
universities these days are willing to admit that any code the produce
was the intended product of their work, so although the government
pays for much of the code produced by our universities, the tendency
is for very little of it to be regarded as covered by the provisions
requiring government-funded code to be public.  Some agencies consider
this a good thing, because they'd rather see the universities have
enough ownership of the code to be able to sell it to a software house
for futher development and eventual marketing.  This is viewed as
"technology transfer", and gets them brownie points.  Agencies
apparently do not view PD software as accomplishing much.  I disapprove
of this trend, and view all of my work as PD, but I seem to be fighting
a losing battle.

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 16:37:00 EDT
From:      alexandr@uiucuxe.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong telnet and new line proc



The bug is in telnetd for the incoming session, not telnet for the outgoing
session.  There is nothing wrong with the pty driver at all.
Here is a diff.  Your line numbers may vary.  The problem is that
someone misread the telnet spec and interpreted "NEWLINE" to mean
UNIX newline character ('\n') not a conceptual end of line.  The
result:  If you telnet into a 4.3 machine (or SUN running 3.2),
you can't telnet out to any non-unix machine.  You can't tip anywhere.
It's a dumb bug, but easy to fix.

-- Steve Alexander
Workstation Development, National Center for Supercomputing Applications
stevea%newton@uxc.cso.uiuc.edu
stevea%newton@uiuc.arpa
stevea%newton@uiuc.csnet
stevea@uiucvmd.bitnet
...!{pur-ee, convex, ihnp4}!uiucdcs!uiucuxc!newton!stevea

----- cut here for diffs ------

*** /tmp/geta2947	Wed Jul 22 15:30:13 1987
--- /tmp/getb2947	Wed Jul 22 15:30:14 1987
***************
*** 637,643 ****
  			if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') {
  				if ((ncc > 0) && ('\n' == *netip)) {
  					netip++; ncc--;
! 					c = '\n';
  				} else {
  					state = TS_CR;
  				}
--- 652,658 ----
  			if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') {
  				if ((ncc > 0) && ('\n' == *netip)) {
  					netip++; ncc--;
! 					c = '\r';
  				} else {
  					state = TS_CR;
  				}

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 87 12:41:31 GMT
From:      mtune!codas!novavax!atlas!jjensen@RUTGERS.EDU  (Jim Jensen)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Wollongong telnet and new line processing
in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says:
> 
> I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS
> system using Wollongong telnet and have discovered an interesting
> problem. Unix uses \n as the line terminator,
>[deleted about sending a \r to VMS]
> Unix translate the \r into a \n and sends it across the net
> [problems this causes on VMS deleted]
> I've modified telnet to send a \r instead of a \n for the line
> terminator. Although I think this is only a work around.
> 
> I say this because if you are connect to the Unix machine
> via a direct line everything works fine. This problem only
> occurs when you are connected via a pty. We use Bridge
> cs/1 terminal servers almost exclusivly, hence you are always
> connected to a pty and never to a direct line. 
> 

(this is my first posting so I dont know if I am doing this right)

I just finished writing telnet for MPX (Gould's real time OS), and ran into 
the same problem.  The bridge box sends a \r\n which is the specifed in the
telnet rfc as the end of line character. which the unix telnet server turns
into a \n.

on telnet 4.2 the  telnet task, converts this back to \r\n 
which the VMS(or MPX)server converts back to a \r and everything works.

4.3 leaves it as a \n, which seems to me to be a clear violation of the 
protocol.  The rfc SAYS that \r\n is the end of line character, not \n.
Thats what protocols are for; To take care of differences between machines.
When a protocol is not followed problems like this happen.

I asked one of our unix people about it, and he said that  
BSD did it on purpose, and it is in telnet. I was unable to convince
him it was a mistake, so he would not change it.  that is until some people
in our unix group tried to use a bridge box. Thus:

 the latest patch to Gould Unix has a telnetd which has a variable that can be
set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes 
the problem.

I am not a unix person, so I may have gotten something wrong about unix, but
I don't think so.
                                              Jim Jensen
					      Gould inc. CSD 
					      6901 West Sunrise Boulevard
					      Ft. Lauderdale Fl 33313-4499
					      (305) 587-2900
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 87 13:02:04 GMT
From:      mtune!codas!novavax!atlas!jjensen@RUTGERS.EDU  (Jim Jensen)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Wollongong telnet and new line processing


in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says:
> 
> I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS
> system using Wollongong telnet and have discovered an interesting
> problem. Unix uses \n as the line terminator,
>[deleted about sending a \r to VMS]
> Unix translate the \r into a \n and sends it across the net
> [problems this causes on VMS deleted]
> I've modified telnet to send a \r instead of a \n for the line
> terminator. Although I think this is only a work around.
> 
> I say this because if you are connect to the Unix machine
> via a direct line everything works fine. This problem only
> occurs when you are connected via a pty. We use Bridge
> cs/1 terminal servers almost exclusivly, hence you are always
> connected to a pty and never to a direct line. 
> 

(this is my first posting so I dont know if I am doing this right)

I just finished writing telnet for MPX (Gould's real time OS), and ran into 
the same problem.  The bridge box sends a \r\n which is the specifed in the
telnet rfc as the end of line character. which the unix telnet server turns
into a \n.

on telnet 4.2 the  telnet task, converts this back to \r\n 
which the VMS(or MPX)server converts back to a \r and everything works.

4.3 leaves it as a \n, which seems to me to be a clear violation of the 
protocol.  The rfc SAYS that \r\n is the end of line character, not \n.
Thats what protocols are for; To take care of differences between machines.
When a protocol is not followed problems like this happen.

I asked one of our unix people about it, and he said that  
BSD did it on purpose, and it is in telnet. I was unable to convince
him it was a mistake, so he would not change it.  that is until some people
in our unix group tried to use a bridge box. Thus:

 the latest patch to Gould Unix has a telnetd which has a variable that can be
set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes 
the problem.

I am not a unix person, so I may have gotten something wrong about unix, but
I don't think so.
                                              Jim Jensen
					      Gould inc. CSD 
					      6901 West Sunrise Boulevard
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 18:16:27 EDT
From:      peter@julian.UUCP
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Async DECnet and MNP modems help

I'm trying to get a dynamic asynchronous DECnet link established between two
VMS machines.  The method of connection is a telephone line and a pair of
Microcom AX/9624c MNP-6 modems running at either 9600bps or 19200bps.

When I follow the instructions, I get the circuit set up, but after a flurry
of activity lasting perhaps 30 or 40 seconds (data transmitted in both
directions) the remote end stops talking and I see periodic polls coming
from the local system.  A SET HOST command to the remote system dies with a
message about a DECnet channel error.  Eventually I hang up the telephone
manually and try to get my async line back.

Does anyone have any experience with this kind of set up?  Has anyone tried
something similar using Serial Line IP (SLIP)?  I'm willing to abandon
DECnet and consontrate on something that will fit in better.  Am I silly to
expect it ever to work?  

Are there any parameters (delays, retransmission...) that I can set to make
this work better?  The modems will be introducing a significant delay as
they try to buffer up and compress and packetize.

Any help would be appreciated.

-- 
Peter Marshall, Data Comm. Manager
CCS, U. of Western Ontario, London, Canada N6A 5B7
(519)661-2151x6032 
pm@uwovax.BITNET; pm@uwovax.uwo.cdn; peter@julian.uucp; ...!watmath!julian!peter

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 18:47:48 EDT
From:      kurt@hi.UUCP (Kurt Zeilenga)
To:        comp.unix.wizards,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   How do you break up a B class number?

Does anyone know of any good references for netmasking (subnets)
schemes to split a B class number into various sized networks?

Here's the problem:

We have out grown our present configuration for IP networking.  We
have a half dozen or so C class networks (not registered), one of
which is filling rapidly.  We will soon be attaching to Internet
and will be using one B class number (registered) for the whole
campus.  We would like to split the B into different sized subnets
say of sizes to support 2 (host-host), 14, 62, 254, 2046 hosts.
On NIC's suggestion, we will use all 1s on a given net for broadcast and
reserve all 0s on a given net.  There will be at least one gateway
to the outside Internet.

What did you do?  If you send your comments to me, I will post a
summary.  If not ....

-- 
	Kurt Zeilenga	 (zeilenga@hc.dspo.gov)		I want my talk.flame!

	"Remember, Mommie, I'm off to get a commie..."

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 87 17:12:21 GMT
From:      ur-tut!ur-cvsvax!srs!dan@cs.rochester.edu  (Dan Kegel)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Streams TCP/IP
> Would someone please summarize why Streams is better...
While we're at it, could anybody summarize the differences between RFS
and NFS?
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Jul-87 22:50:43 EDT
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re: TWG on MILNET?

Dennis,

I was told by one of our DDN planners just a few days ago that Arpanet
was most definitely not considered to be part of the DDN.  I pointed that 
most of the DDN transition charts I've seen show many nets, including
Arpanet, merging into an internet called DDN.  He assured me, however, 
that when all is done, Arpanet will not be part of DDN.  I remain
puzzled.  

Now I guess the next question is- is Arpanet really an experimental network
for network research or an operational network for use by researchers?

Phill

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 01:57:54 EDT
From:      monkey@unixprt.UUCP (Monkey Face@unixprt)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes:
> Would someone please post a summary of reasons why use of Streams is
> an advantage...  is there  a reason Streams is better?  than sockets?... 
> Does the end user see any advantage?...
>   Thanks,
>      Mel Haas  ,  odyssey!mel

First it is STREAMS, as apposed to Streams, streams, this differenciates it 
from a stream based environment.

The primary advantage, for those using ATT based UNIX, is that this is the
only 'real' facility provided in UNIX System V to support networking.  It
basically provides the 'structure' that allows layered protocols a
consistent interface to other layers in a somewhat independent manner.
It is not necessarily 'better', but it is a more appropriately structure
for the varying protocols than other implementations (such as the
4.x BSD architecture).  Hopefully the 'end-user' doesn't get involved
at this level.  ATT's Transport Interface is mostly base on the ISO
transport interface, therefore should map to the emerging interface 
standards.  I have found that performance is not considerably 
different in s STREAMS based vs. 4.x BSD based implemetnation of TCP/IP.

Monkey Face - uni-xperts

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 07:05:44 EDT
From:      jqj@gvax.cs.cornell.edu (J Q Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you break up a B class number?

In article <11636@hi.UUCP> kurt@hc.dspo.gov (Kurt Zeilenga) writes:
>Does anyone know of any good references for netmasking (subnets)
>schemes to split a B class number into various sized networks?

Although variable-sized subnets may work for some network topologies,
they are almost guaranteed to get you into trouble, and I strongly
recommend that you avoid them.  Consider a subnet (perhaps the backbone)
with two or more gateways.  Host A on this subnet wants to send a packet
to host B on a different subnet.  In order to look up the route to B,
A needs to decompose B's address into net-subnet-host, so he needs to
know B's subnet mask.  All current software that I know of will use
A's mask, and ASSUME that it is the same size as B's.

Granted you can fool the routing tables in some topologies, e.g.  a
network with subnet mask of 255.255.255.0 containing several subsubnets
(who think the subnet mask is 255.255.255.188 or something) all
connected to only a single (hacked) gateway, where that gateway 
advertises a subnet that is the union of the subsubnets.  It will break 
as soon as you make the topology more complex!

Given that we can't do what Zeilenga asks, is it perhaps time to rethink
the whole subnet scheme?  16 bits of hostnumber is not much at all for
a typical large organization (say a university), especially if we have
to waste most of it because of subnet constraints.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 08:20:23 EDT
From:      HANK@BARILVM.BITNET (Henry Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Looking for someone from ACC

If someone reading this is from ACC (Advanced Computer Communications -
makers of ACCES/MVS and ACC 9310) could you please drop me a note
via the network.

Thanks,
Hank

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 09:27:25 EDT
From:      heath@ncrcae.Columbia.NCR.COM (Robert Heath)
To:        comp.protocols.tcp-ip
Subject:   Wanted: Network Independent File Transfer Protocol (NIFTP)

I am looking for the source to a UNIX-based implementation of 
Network Independent File Transfer Protocol (NIFTP).
NIFTP is used mainly in the UK (& New Zealand) to move files around
X.25 networks.

I am informed that Internet Protocol versions of NIFTP exist,
but I am interested only in using the OSI Transport layer over X.25 version. 
My goal is to port NIFTP to an NCR TOWER running UNIX 5.2.

I'd like to hear the opinion of any NIFTP users on how well it works and 
to discuss possible interconnection.

I have the names of two other interested parties which I picked up
from an earlier, unsuccessful posting to comp.sources.wanted.
Thanks in advance.

	Robert A. Heath
	ncrcae!heath or heath@Columbia.NCR.COM
	NCR Dept 783
	3325 W. Platt Springs Rd.
	W. Columbia, SC 29169
	(803)-791-6492

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 10:26:48 EDT
From:      kp@hjuxa.UUCP (Karen Paszamant)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   RE: Streams TCP/IP Vendors

Thanks for the info on vendors.  I ordered the book from SRI
but have still not received it.  In case anyone else is interested,
here is a summary of Streams based TCP/IP vendors for Sys V Release 3.0:

1.  Spider Systems, Edinburgh, U.K.
2.  Counterpoint Computers
3.  Micom Interlan - they used Lachmans TCP/IP
4.  Uniq Digital Technologies, Batavia, ILL. 1-800-DEC-UNIX
5.  The Wollongong Group, Palo Alto, CA
6.  Lachman Associates, Naperville, ILL. - they worked with Convergent
    Technologies to develop product.

Karen
hjuxa!kp

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 10:28:23 EDT
From:      ajr@hjuxa.UUCP (Karen Paszamant)
To:        comp.protocols.tcp-ip
Subject:   NFS on system V

I am looking for a port of NFS for System V release 2 or 3.
Does any one know if it exists. What kind of environment
is it running in? How is the performance and bugs?
Does it come with Yellow pages and XDR?

Thanks
hjuxa!ajr

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 11:51:08 EDT
From:      bob%tut.cis.ohio-state.edu@osu-eddie.UUCP (Bob Sutterfield)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

In article <314@uniq.UUCP> news@uniq.UUCP (Usenet Administration) writes:
>In article <725@hjuxa.UUCP>, kp@hjuxa.UUCP (Karen Paszamant) writes:
>> Does anyone know what vendors have a System V Release 3.0
>> streams based tcp/ip product?
>Uniq Digital Technologies supports UNIX System V Release 3 TCP/IP for
>VAX processors.  ...  Contact Trish Halleen on 1-800-DEC-UNIX ...

I just did.  I was about the dozenth person who had inquired whether
they do IP on 3B2s under SVr3 too (which they don't), and whether they
planned to (ditto).  *Disappointment*.  I guess I'm stuck with TWG.
-=-
 Bob Sutterfield, Department of Computer and Information Science
 The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
 bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-eddie!bob
 soon: bob@aargh.cis.ohio-state.edu

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 12:41:46 EDT
From:      mrose@GREMLIN.NRTC.NORTHROP.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP question


    I don't know what the "official" word is, but SMTP is designed for
    moving ascii messages.  Although the gurus will probably tell you
    otherwise, SMTP is very dependent on rfc822, which defines the
    format of text messages.  This probably isn't the fault of SMTP,
    since all of the mailers which use SMTP also depend on rfc822 or
    rfc822-like formats being used.  

    If you want to use SMTP to move arbitrary octets in messages, then
    on UNIX, using something like atob and btoa.  btoa takes a "binary"
    stream (8-bit bytes) and explodes it into a 7-bit data path with
    line breaks at column 78 (or something like that); atob performs the
    inverse operation.  I'm sure other systems have similar programs.  

    Alternately, find someone running X.400 in the Internet and just use
    X.400.  Of course, it's probably going to be another three years
    before X.400 mailers will have the reach of SMTP mailers.  

/mtr

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 13:37:24 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  SMTP question

I strongly object to modifying SMTP and RFC822 to allow for this.
Lets keep plaintext plain.  If you wish to enhance mail, try the
multimedia mail project.  The main problem with the existing Multimedia
project is that NOBODY OBEYS THE SPECIFICATION.  Hence messages from
DIAMOND are unreadable on other systems.

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 14:29:03 EDT
From:      peter@julian.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for VAX/VMS

I recently posted a message saying that Digital was now not recommending
TWG software for VMS machines.  I got a call last night from TWG following
up on my message.  They wanted to find out what specific problems that we
have been having with their software.  (We don't have a copy,
unfortunately.)  It looks to me as if their new Vice-president is having
some effect.  They are making an effort to improve their image.  It could be
more than skin deep.
-- 
Peter Marshall, Data Comm. Manager
CCS, U. of Western Ontario, London, Canada N6A 5B7
(519)661-2151x6032 
pm@uwovax.BITNET; pm@uwovax.uwo.cdn; peter@julian.uucp; ...!watmath!julian!peter

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 14:39:41 EDT
From:      guy%gorodish@Sun.COM (Guy Harris)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

> The primary advantage, for those using ATT based UNIX, is that this is the
> only 'real' facility provided in UNIX System V to support networking.

Gee, for some time now the people at Berkeley have been using an
"AT&T-based UNIX" (the only non-"AT&T-based" UNIXes I know of are
things like Mark Williams' "Coherent", which was written from
scratch) that supports networking without STREAMS.  Plenty of other
people have dropped the socket code into System V kernels, just as
Berkeley dropped it into a 32V-derived kernel, so STREAMS are not
"the only game in town".

> ATT's Transport Interface is mostly base on the ISO transport interface,
> therefore should map to the emerging interface standards.

Unfortunately, the TLI also has a number of warts, such as the fact
that it keeps some state both in userland and in the kernel, so that
after a "fork"/"exec" you have to issue a "t_sync" call to pull the
kernel's notion of the state into userland.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 14:52:58 EDT
From:      Okuno@SUMEX-AIM.STANFORD.EDU (Hiroshi "Gitchang" Okuno)
To:        comp.protocols.tcp-ip
Subject:   Help: TCP/IP for business application

I'd like to know whether TCP/IP is really used for business
applications or distributed processings.  Or is it used only for
computational environments (Telnet, FTP, SMTP, NSF, windows)?
Any information or pointer is welcome.

Thanks in advance,

- Gitchang -
-------

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 16:03:32 EDT
From:      rick@ut-ngp.UUCP (Rick Watson)
To:        comp.protocols.tcp-ip
Subject:   Re: TWG questions

> Dbridge in Version 2 of the code is abysmal.  I don't know if it is
> fixed in 3.0 since I now have a real IP path between the two sites.
> It would be nice if Woolongong would take the effort of reversing this
> product (allowing DECNET to flow through their IP paths) but it probalby
> isn't an easy modification.
> 
> -Ron

*Flame on*
Saying that "Dbridge [...] is abysmal" is not really very informative.
What specifically did you have problems with?
*Flame off*

We have been using DBRIDGE under v2.x (and now 3.0) with good performance
under light to moderate usage (say 1-4 "active [currently transferring data]"
circuits in/out of each node).  Performance will (of course) be dependent
on DECnet circuit speed and loading.  Our topology looks like:

192.16.73---ether     --+--128.83-----ether-+---------
       |     |...       |                   |      |...
     +---+            +---+               +---+
     |   |            |   | UTADNX        |   |--- 10 (arpanet)
     +---+            +---+               +---+
       |                |
     ---DECnet 192.16.72-----
       |      |      |     |
     +---+  +---+  +---+ +---+        
     |   |  |   |  |   | |   |
     +---+  +---+  +---+ +---+

with DBRIDGE/DECnet making the connections for the network 192.16.72
over serveral leased phone lines that run at 56KB, 230.4KB and ~760KB.
The CPU overhead for the DBRIDGE process on UTADNX can get to be high
if it is having to route too many packets on to 128.83 and beyond.  It
really needs to be a dedicated uVax.  It would be nice if the DBRIDGE
interface could live in the WIN/TCP kernel (like ELINK does now),
instead of a user-mode process, but I have no idea if that is possible.

Rick Watson
University of Texas Computation Center
 arpa:   ccaw001@utadnx.cc.utexas.edu rick@ngp.utexas.edu
 uucp:   ...seismo!ut-sally!ut-ngp!rick
 bitnet: ccaw001@utadnx
 phone:  512/471-3241

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 16:04:39 EDT
From:      wayne@ultra.UUCP (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Re: Berkeley (not wollongong!) telnet and new line processing

Apropos of not much more than "Nothing new under the sun," a small war
story about TELNET end-of-lines.  Back about 15ish years ago I had the
dubious pleasure of trying to shoehorn an IBM system into the ARPANET
world.  In particular, we used the IBM 2741, a half-duplex Selectric
typewriter ("Mother of the TELNET go-ahead"*).  Among the 2741's
endearing qualities was that it had no <CR> key.  It had "INDEX,"
which did a <LF>, and it had "RETURN," which did a combined <CR><LF>
(actually the EBCDIC "newline" character); the only way to output a
naked <CR> was to backspace all the way to the beginning of the line!

In actual operation, this caused no real problem, because of course my
user TELNET was smart enough to translate TELNET end-of-line
(<CR><LF>) into EBCDIC "newline," and naked <CR>s were pretty rare.
Except in one case: good old Multics (or at least one generation of
Multics TELNET), which for some unknown reason insisted on ending
every line with <CR><NUL><LF>.  Decidedly nonconforming for sure, but
completely transparent to almost every other ARPANET host, so why
change?  Anyway, whenever I logged into Multics from a 2741 I got the
following behavior:

 typey-typey-typey-typey-backspace-backspace-backspace-backspace-index
 typey-typey-typey-typey-backspace-backspace-backspace-backspace-index
 typey-typey-typey-typey-backspace-backspace-backspace-backspace-index
 typey-typey-typey-typey-backspace-backspace-backspace-backspace-index

Ad nauseum.  But the most interesting thing was that in spite of
everything taking more than twice as long (plus shaking everything off
the typing table), the output ended up being exactly correct!  Amazing
what can pass for "interoperability" ...

            Wayne Hathaway        ultra!wayne@Ames.ARPA
            Ultra Corporation
            2140 Bering drive     with a domain server:
            San Jose, CA 95131       wayne@Ultra.COM
            408-922-0100

* There was at least one other name for the 2741 that also started
  with "Mother."  Fun gadget ...

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 16:25:53 EDT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   IBM TCP.

I heard an interesting rumor that the IBM distributed TCP/IP
source routes all its packets.

Is this possibly true????

BillW
-------

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Jul-87 17:25:05 EDT
From:      mark@applix.UUCP (Mark Fox)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

In article <278@unixprt.UUCP> monkey@unixprt.UUCP (Monkey Face@unixprt) writes:
>In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes:
>> Would someone please post a summary of reasons why use of Streams is
>> an advantage...  is there  a reason Streams is better?  than sockets?... 
>> Does the end user see any advantage?...
>
>The primary advantage, for those using ATT based UNIX, is that this is the
>only 'real' facility provided in UNIX System V to support networking.

Possible, but have you seen HP's or CPC's implementation of sockets in their
System V ports? Looks plenty "real" to me and cleanly done as well.

>It is not necessarily 'better', but it is a more appropriately structure
>for the varying protocols than other implementations (such as the
>4.x BSD architecture).

What do you mean by "a more appropriate[ly] structure"?  Could you back this up
or is this only an opinion?

>Hopefully the 'end-user' doesn't get involved
>at this level.

But with 4.x all the end-user needs to know is a host name in order to use
the Berkeley "r" utilities assuming NFS across remote mount points is not being
used instead.

>ATT's Transport Interface is mostly base on the ISO
>transport interface, therefore should map to the emerging interface 
>standards.

But its easy enough to add new socket types as Sun has for its
OSI protocol implementation.

>I have found that performance is not considerably 
>different in s STREAMS based vs. 4.x BSD based implemetnation of TCP/IP.

So?

>Monkey Face - uni-xperts

What're those?

Don't get me wrong - I'm not a socket bigot - but I have never seen an
implementation of streams and I am still curious why some people prefer them.

-- 
                                    Mark Fox
       Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300
                    uucp:  seismo!harvard!m2c!applix!mark

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jul 1987 15:20:23 P
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Looking for someone from ACC
If someone reading this is from ACC (Advanced Computer Communications -
makers of ACCES/MVS and ACC 9310) could you please drop me a note
via the network.

Thanks,
Hank
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 00:18:39 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Uselessness

Craig,

Without addressing your comment that "TCP/IP is in fact a Bad Idea," I
might conclude from your remarks that public X.25 networks may have
to either surcharge or prohibit use of connectionless protocols over
virtual circuits. This is an interesting issue which should be raised
within the ANSI X3S3.3 committee. I also conclude from your remarks that
the public X.25 community has come up with "a scheme that doesn't hammer
the network to its knees when something goes wrong." Please, I desperately
need to know what scheme you have in mind.

Dave

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1987 10:32-PDT
From:      STJOHNS@sri-nic.arpa
To:        dab%oliver.cray.com@umn-rei-uc.arpa
Cc:        tcp-ip%sri-nic.arpa@umn-rei-uc.arpa
Subject:   Re: IP Security option
IA copy of the IP security option as (supposedly) approved by the
protocol     standards     steering     group     resides      in
[sri-nic]PS:<StJohns>ipso.txt.    LoginVia   anonymous   ftp   to
retrieve it.  Mike
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 09:27:08 EDT
From:      daveb@geac.UUCP (Dave Brown)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

In article <561@applix.UUCP> mark@applix.UUCP (Mark Fox) writes:
>>In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes:
>>> Would someone please post a summary of reasons why use of Streams is
>>> an advantage...  is there  a reason Streams is better?  than sockets?... 
>>> Does the end user see any advantage?...
>...
>Don't get me wrong - I'm not a socket bigot - but I have never seen an
>implementation of streams and I am still curious why some people prefer them.

  There is interest in streams for several reasons.
	1) It looks elegant.
	2) It comes from an acknowleged Unix expert.
	3) It *looks* (emphais added) more general than sockets.
	4) It allows a structured decomposition of some of the
  	   hot-spots in Unix (terminal handling, protocols)	
 	   into subparts which can be placed on a front-end
	   processor.
  There is use of streams for other reasons.
	1) Bell provides it instead of sockets.
	2) Some customers will buy anthing that Berkley *doesn't* make.
	3) Some system/hardware designers want (4) above.
	4) Some system/hardware designers have fallen in love with 
	   any of the above.

  Personally, I like (4), having worked on a machine which used
FEPs effectively (as well as two which didn't, all from the same
manufacturer!).

	--dave (unix hack on a 'bun) collier-brown


-- 
 David (Collier-) Brown.              |  Computer Science
 Geac Computers International Inc.,   |  loses its memory
 350 Steelcase Road,Markham, Ontario, |  (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 87 09:37:18 EDT
From:      jqj@gvax.cs.cornell.edu (J Q Johnson)
To:        arpa.tcp-ip
Subject:   variable sized subnets
In article <11636@hi.UUCP> on comp.protocols.tcp-ip, kurt@hc.dspo.gov 
(Kurt Zeilenga) writes:
>Does anyone know of any good references for netmasking (subnets)
>schemes to split a B class number into various sized networks?

Although variable-sized subnets may work for some network topologies,
they are almost guaranteed to get you into trouble, and I strongly
recommend that one avoid them.

Given that we can't do what Zeilenga asks, is it perhaps time to rethink
the whole subnet scheme?  16 bits of hostnumber is not much at all for
a typical large organization (say a university), especially if we have
to waste most of it because of subnet constraints.

Why don't variable sized subnets work?  Routing and broadcast.  Broadcast
isn't too bad as long as all hosts have the "correct" subnet mask set for
their size of subnet and gateways don't leak broadcasts off the local
subnet, but routing is a problem.  Consider a subnet (perhaps the backbone)
with two or more gateways.  Host A on this subnet wants to send a packet
to host B on a different subnet.  In order to look up the route to B,
A needs to decompose B's address into net-subnet-host, so he needs to
know B's subnet mask.  All current software that I know of will use A's
mask (for 4.3BSD, the mask for the first interface on that network!), and
ASSUME that it is the same size as B's.

Granted you can fool the routing tables in some topologies, e.g. a
network with subnet mask of 255.255.255.0 containing several subsubnets
(who think the subnet mask is 255.255.255.188 or something) all
connected to only a single (hacked) gateway, where that gateway 
advertises a subnet that is the union of the subsubnets.  It will break 
as soon as you make the topology more complex!

Am I missing something?  Has anyone successfully made variable-sized subnets
work in a real (multivendor, multisubnet) environment?  Does anyone have
suggestions for a clean way to make them work?
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 09:59:39 EDT
From:      mcc@ETN-WLV.EATON.COM (Crockett)
To:        comp.protocols.tcp-ip
Subject:   <CR><LF> Processing

I don't have a copy of RFC 854; however, I do  have  MIL-STD-1782  which
defines  the implementation requirements for the TELNET Protocol for DDN
MILNET and other DDN subnetworks.  The end of line character is  a  <CR>
which  moves  the  cursor  or print head to the beginning of the current
line.

The standard became confusing when it attempted to  accomodate  physical
terminals that generate a <CR><LF> sequence when the ENTER or RETURN key
is struck.  To permit the use of these terminals a two octet end of line
function  (ELF)  was  defined.  For terminals that could generate a <CR>
and a <LF> independently, the ELF was defined to be  a  <CR><NUL>.   For
those that couldn't, the ELF was defined to be <CR><LF>.

Regardless  of  any echo options that may be in effect, the user (local)
host is responsible for transmitting only the keyboard  input  from  the
terminal  to  the  server  (remote) host.  If the RETURN key generates a
<CR><LF>, it is to be mapped to a <CR><NUL> prior to  transmission  over
the  network.  If the NVT is being operated in its default line buffered
full duplex mode  with  local  echo,  the  user  host  echoes  both  ELF
variations as a <CR><LF> to the terminal display.

At  the  server  host  <CR>,  <CR><NUL>,  and <CR><LF> are to be treated
identically and  mapped  to  the  host's  local  interpretation  of  the
character  or  character  sequence  that  is  passed  to the application
software when the RETURN key is struck.  When  the  virtual  circuit  is
being  operated in half duplex mode with the server echoing data back to
the user, it transmits either a <CR><NUL> or <CR><LF> with the ELF  form
being dependent upon the server's local convention.

The  original  problem  that  raised  the  question of the NVT ELF was a
difference in operation when a terminal (workstation) was connected on a
local  LAN  segment  or  on  a remote LAN segment requiring the use of a
gateway to make the transition between the LAN segments.  The answer  is
that  both  Woologong  and  the  Bridge  CS/1  have  errors or have been
configured incorrectly.

Any host in the network that functions as a gateway is  responsible  for
ensuring  that  the  data  transmitted is the same as what was received.
The sequences <CR><LF> and <CR><NUL><LF> are not necessarily equivalent.
The gateway can not compress the sequence <CR><NUL><LF> to <CR><LF>.

The  problem  I  have  seen  with  a  number of hardware and/or software
products that implement TCP/IP, TELNET, FTP, SMTP, and UDP is  that  the
vendor has based his product on the 4.x bsd implementation.  The problem
with the vendors that have done that is that they have failed to go back
through  the software and remove all the tacit assumptions that the host
system will be running a UNIX or UNIX derivative operating system.  Some
vendors  have  even  removed  code to support the options that are to be
negotiated always responding with a DO  or  WILL  when  they  should  be
responding  with  a DON'T or WON'T because they know that 4.x bsd always
attempts to negotiate to the same mode of operation.

Invariably these products have problems when one attempts to use them on
a  PDP11  or  VAX  based  AN/GYQ-21(V) systems which use the IAS and VMS
operating systems, respectively.

	Merton Campbell Crockett	mcc@etn-wlv.eaton.com
	AN/GYQ-21(V) Program

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 87 13:18:42 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Naming the NIC

Hey guys,

    There is a forum for these sorts of naming issues -- the namedroppers list.

    I recommend that any continued debate migrate to that list and will even
be so good as to resist the instinct to point out that the issue of how
to name NICs and NOCs was settled (I thought) over a year ago.

Craig Partridge
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 10:48:00 EDT
From:      M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon)
To:        comp.protocols.tcp-ip
Subject:   Name of NIC (was: twg, and nic not knowing its domain name..)

Oh, so there would be MILNET.NIC and ARPANET.NIC and NYSERNET.NIC 
and BITNET.NIC? Good idea!

--jsol

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 12:51:56 EDT
From:      dab@oliver.cray.COM (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   IP Security option


I seem to recall that at the Monteray TCP/IP conference last fall, there
was some discussion that the IP Security option was being re-written, and
that there would be an RFC out that described the new scheme.  Has anything
progressed in this area?  Is there a new RFC that talks about the IP
Security option?  Any pointers to what the current status is would be
appreciated.
			-Dave Borman
			Cray Research, Inc.
			dab@umn-rei-uc.arpa

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 13:04:07 EDT
From:      jmc@ptsfa.UUCP (Jerry Carlin)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS on system V

In article <731@hjuxa.UUCP> ajr@hjuxa.UUCP (Karen Paszamant) writes:
>I am looking for a port of NFS for System V release 2 or 3....
>Does it come with Yellow pages and XDR?

Arete release 3.8 (V.2) supports NFS including YP and XDR. They are using
an Excelan Ethernet board with EXOS software.

-- 
voice: (415) 823-2441	uucp: {ihnp4,lll-crg,ames,qantel,pyramid}!ptsfa!jmc
Where am I? In the village. Whose side are you on? That would be telling.

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 13:32:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: IP Security option

IA copy of the IP security option as (supposedly) approved by the
protocol     standards     steering     group     resides      in
[sri-nic]PS:<StJohns>ipso.txt.    LoginVia   anonymous   ftp   to
retrieve it.  Mike

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 13:39:34 EDT
From:      hoey@NRL-AIC.ARPA (Dan Hoey)
To:        comp.protocols.tcp-ip
Subject:   Re: new lines


    Date: Mon, 20 Jul 87 19:55 PDT
    From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>
    Subject: Re: wollongong telnet and new line processing
    To: tcp-ip@sri-nic.ARPA
    X-Vms-To: IN%"tcp-ip@sri-nic.arpa"

    I traced the problem to the fact that "telnetd.c"
    has the following in it:
    ...

What's really laughable about the 4.3 code is that if the <CR><LF> is
split across whatever buffer boundary telnetd is using, the code turns
it into <CR> instead of <LF>.

    I don't think it's right to map <CR><LF> to <LF>.  I changed it to map
    to <CR> instead, and everything works just fine.

    ...I suppose another approach might be to say that the Bridge TELNET
    code is broken and that it shouldn't be sending <CR><LF> when you type
    "carriage return" but should send <CR><NUL>....

Well, given that <CR><LF> is supposed to be the ``normal'' line
terminator, it should probably correspond to the big button on your
keyboard.  The real bug in the Bridge TELNET is that it apparently
gives the user no way of sending a <CR><NUL>.  Telnet user programs
should provide some way of sending all three of <CR><NUL>, <CR><LF>,
and <LF>.  On two-button keyboards (RETURN/LF or RETURN/INDEX) this
probably means you need to be able to tell telnet what mapping you
want.

Dan

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1987 13:39:34 EDT (Fri)
From:      Dan Hoey <hoey@nrl-aic.ARPA>
To:        tcp-ip@sri-nic.arpa
Cc:        Kevin Carosso <KVC%YMIR.BITNET@wiscvm.wisc.edu>, uxc.cso.uiuc.edu!uiucuxe!alexandr@a.cs.uiuc.edu
Subject:   Re: new lines
    Date: Mon, 20 Jul 87 19:55 PDT
    From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>
    Subject: Re: wollongong telnet and new line processing
    To: tcp-ip@sri-nic.ARPA
    X-Vms-To: IN%"tcp-ip@sri-nic.arpa"

    I traced the problem to the fact that "telnetd.c"
    has the following in it:
    ...

What's really laughable about the 4.3 code is that if the <CR><LF> is
split across whatever buffer boundary telnetd is using, the code turns
it into <CR> instead of <LF>.

    I don't think it's right to map <CR><LF> to <LF>.  I changed it to map
    to <CR> instead, and everything works just fine.

    ...I suppose another approach might be to say that the Bridge TELNET
    code is broken and that it shouldn't be sending <CR><LF> when you type
    "carriage return" but should send <CR><NUL>....

Well, given that <CR><LF> is supposed to be the ``normal'' line
terminator, it should probably correspond to the big button on your
keyboard.  The real bug in the Bridge TELNET is that it apparently
gives the user no way of sending a <CR><NUL>.  Telnet user programs
should provide some way of sending all three of <CR><NUL>, <CR><LF>,
and <LF>.  On two-button keyboards (RETURN/LF or RETURN/INDEX) this
probably means you need to be able to tell telnet what mapping you
want.

Dan
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 13:43:41 EDT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Naming the NIC


Hey guys,

    There is a forum for these sorts of naming issues -- the namedroppers list.

    I recommend that any continued debate migrate to that list and will even
be so good as to resist the instinct to point out that the issue of how
to name NICs and NOCs was settled (I thought) over a year ago.

Craig Partridge

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 15:55:35 EDT
From:      unni@sdcrdcf.UUCP (Unni Warrier)
To:        comp.protocols.tcp-ip
Subject:   Mailing list on modeling/simulation of networks

This is to announce the start of a new mailing-list devoted to network modeling 
and simulation.  Sorry for the cross-postings to many groups, but we aim to 
reach as wide an audience as possible.  We expect to cover the following broad 
areas:
	Networks modeling, Queueing theory as applied to networks
	Simulation, Distributed simulation
These topics are furthur described at the end of this article.
Please send in your requests to be included in this list, because if I get a
large enough number, we can get our own newsgroup.

All requests for inclusion in the mailing list should be sent to 
..!sdcrdcf!sdcjove!modsim-request               OR
"modsim-request@cam.unisys.com"
All articles for inclusion should be sent to 
..!isdcrdcf!sdcjove!modsim                      OR
"modsim@cam.unisys.com"
Any private correspondence regarding the list should be sent to me at
..!sdcrdcf!sdcjove!unni                         OR
"unni@cam.unisys.com"

TOPICS FOR DISCUSSION:

a.  Networks modeling
There is a lot of work in the literature on modeling networks, typically as
a network of queues.  However, for large networks, the computations become 
intractable and we are forced to move to even more approximte models.  
* An example is the ARPANET, where the congestion problem has not been 
  satisfactorily analyzed. 
* Some groups are working on providing network 
  management mechanisms. Will these include performance "hooks"? 
* A new generation of high-speed fibre-optic based networks is coming into 
  being.  What are the models available for these networks?  
* What do we know about interconnection structures like the hypercube? What
  is the experience of people in the field?
* A lot of work has been done on applying queueing theory to networks.  
  What is the practical experience of net-people in applying these results 
  to real-life network problems?  

b.  Simulation of networks
* What is the experience of net-people on simulation of networks?  
* What are your opinions on simulation vs closed-form solutions?  
* How well does simulation agree with real measurements?  
* What are the tools people are using for simulation?  Do object-oriented 
  languages provide any better simulation environments than "ordinary" 
  simulation tools like Simscript, GPSS, PAWS?  
* What are the experiences of net.people with specific tools? 
* Does distributed simulation offer improved performance over uni-processor
  simulation?  Does anyone have any experiences they wish to communicate?

I fully realize that the areas outlined above are very large in scope, but the
idea is to get a discussion going.  As the group expands, we can spin off
more selective areas into new newsgroups.  I will "moderate" this list 
until someone more qualified volunteers, or we get a real newsgroup going.
If I get enough responses, I will try to push the net.gods into giving us our 
own newsgroup.  
unni

UUCP:     ..!sdcrdcf!sdcjove!unni
ARPA:                               unni@cam.unisys.com
Ma Bell (may she rest in peace!):   (213) 829-7511 X 5694
US mail:                            Unni Warrier, Unisys, MS 41-02,
                                    2400 Colorado Ave, Santa Monica CA 90406

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jul 87 18:22 EST
From:      "Salomon Bros. Inc - Maarten Nederlof" <SALOMON@wharton-10.arpa>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Info Request - 802 Spec Group Addressing / TCP File Server

We would like to investigate in pilot form the use of 802 spec "Group
Addressing."  I would be very interested if anyone on this list has had
any experience with using ethernet interfaces for UNIX workstations (SUN,
APOLLO, IBM-RT, IBM/AT) that support group addressing (hardware) and 
provide ON-BOARD processing of the TCP/IP protocols.

We are also interested in disk servers that support not only firm-ware
TCP/IP, but also allow for SNA and X.25 gateways in the same box.  Is there
such an animal?

Anyone that has such interfaces or equipment, or if anyone has done a review
of such vendors, please drop me a note.  I will gladly summarize to the net.

Maarten Nederlof

Salomon Brothers Inc
One New York Plaza
New York, NY 10004
(212) 747-4238
SALOMON@WHARTON.UPENN.EDU
SALOMON@WHARTON-10.ARPA
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 19:00:59 EDT
From:      dennist@tekgen.TEK.COM (Dennis Thomas)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   CMU-TEK TCP/IP


The distribution of the Tektronix VMS TCP/IP software to non-profit
organizations has been changed, effective immediately. Carnegie Mellon
University (CMU) and Tektronix (TEK) have agreed to a change in the method
of distribution of the CMU-TEK VMS TCP/IP software. The major aspects of this
distribution are:

    1. The new distribution software will be called CMU-TEK IP package, and
    will be distributed by CMU.

    2. CMU-TEK IP software will not require a separate license from TEK; only
       the CMU license will be required.

    3. CMU-TEK IP will be licensed to be used on all DEC Computers including
       workstations, such as the Micro-vax II.

    4. CMU-TEK IP will be distributed in object and source formats.

    5. All unfilled and future requests to Tektronix will be forwarded
       to CMU for actual distribution.

    6. CMU-TEK IP software will be available to non-profit and commercial
       organizations.

    7. All requests and enquires for CMU-TEK IP should be sent to:

       CMU-TEK IP Software Request
       Computing Services
       Carnegie Mellon University
       4910 Forbes Avenue
       Pittsburgh, PA 15213-3890



       Dennis Thomas				John Leong
       Mgr. Engineering Network Services	Director of Networking
       Tektronix, Inc.				Carnegie Mellon University
       P.O. Box 500  DS 50-454			Pittsburgh, Pennsylvania
       Beaverton, OR 97077					 15213-3890

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 19:22:00 EDT
From:      SALOMON@WHARTON.UPENN.EDU ("Salomon Bros. Inc - Maarten Nederlof")
To:        comp.protocols.tcp-ip
Subject:   Info Request - 802 Spec Group Addressing / TCP File Server


We would like to investigate in pilot form the use of 802 spec "Group
Addressing."  I would be very interested if anyone on this list has had
any experience with using ethernet interfaces for UNIX workstations (SUN,
APOLLO, IBM-RT, IBM/AT) that support group addressing (hardware) and 
provide ON-BOARD processing of the TCP/IP protocols.

We are also interested in disk servers that support not only firm-ware
TCP/IP, but also allow for SNA and X.25 gateways in the same box.  Is there
such an animal?

Anyone that has such interfaces or equipment, or if anyone has done a review
of such vendors, please drop me a note.  I will gladly summarize to the net.

Maarten Nederlof

Salomon Brothers Inc
One New York Plaza
New York, NY 10004
(212) 747-4238
SALOMON@WHARTON.UPENN.EDU
SALOMON@WHARTON-10.ARPA

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 20:48:47 EDT
From:      rwhite@nu3b2.UUCP (Robert C. White Jr.)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP


This is a semi-informed retelling...

	As I understand it, STREAMS is/are intelegent filter devices.  As
such some of the filters can be "multiplexing".  You can "open" a "stream
head" to a multiplexing STREAMS module and then connect a potentally infinite
number of other STREAMS  and still only have one "open" counting against
your allowed maximum.
	Since all files are STREAMS you can pass whole file descriptors
between processes through an IOCTL call [FD_GIVE and FD_RCV or somesuch].
The flexability is very interesting, and seems to allow recursive nesting
of STREAMS modules such that you decide which "layer" you wish to work
with depending what stream head you open.

i.e.  Starlan support for the 3B2 [from program level] requires you use
a strange set of primitives to establish the link [they are all in a
library] but after you have the link you ay "push" a module on the
stream which makes read, write, putsg, and getmsg the [only] valid
primitives against the stream.  [you can't use read etc. while you are
useing the deeper t_primitive calls]  What this means is, you can open
a connection accross a/the network then "push" the module and pipe
the connection through any normal means.  when the subtask/pipe exits
you pop the module off the stream and terminate the connection.
	It all looks very interesting, I am watching this stuff
carefully, but I havn't been able to upgrade my OS yet so I don't know
how well it works first hand.


Robert.

Disclaimer:  My mind is so fragmented by random excursions into a
	wilderness of abstractions and incipient ideas that the
	practical purposes of the moment are often submerged in
	my consciousness and I don't know what I'm doing.
		[my employers certainly have no idea]

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Jul-87 23:32:20 EDT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: IBM TCP.


    I heard an interesting rumor that the IBM distributed TCP/IP
    source routes all its packets.
     
    Is this possibly true????
     
    BillW
    -------

What I have been told is this:

1. IBM's TCP/IP for the PC, as released for use on their Token Ring Adapter,
does not ARP in the conventional sense:  Instead, it sends the ARP as an
"all rings" broadcast, with an empty Routing Information Field.  When the
reply comes back, it looks for the filled-in RIF field, and uses it.  No
RIF field, no function.

2. IBM's TCP/IP for AIX can behave as above, but only if you enable it
with some magic switch.

3. Other IBM TCP/IP products will try the "all rings" approach, but only
if they get no reply to a conventional ARP.

4. IBM bridges don't pass conventional (not "all rings") broadcasts.

So, yes, folks, source routing is alive & well at Yorktown, whether or not
ISO has accepted it.  No official position is being stated here, but comments
I've heard range from "That's WRONG!  Let's try to talk them into conforming."
to "Oh, hell, they won't listen, and they're going to sell piles of that
junk - It's gonna be a dirty job, but we'd better change the code..."

I've heard nothing about aberrant behavior on Ether, so apparently they're
only punishing their own pioneering customers at the moment....

jbvb

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25-Jul-87 14:33:04 EDT
From:      schoch@ames.UUCP (Steve Schoch)
To:        comp.protocols.tcp-ip
Subject:   Why are these hosts trying to connect?

A while back, out of curiosity, I added a line to our kernel on ames.arpa
that logs a message when a host tries to connect to a TCP port on ames
on which no process is listening (i.e. when ames sends back a packet with
the reset bit set in response to a SYN).  Since we run most of the common
servers on ames, I expected to get a few messages if someone played around
trying random ports on our machine.  I log the foreign address and the
destination port i.e. the port on ames to which a connection is attempted.
What surprised me is how many messages I got.  Here are a couple pages of
log messages:
----
Jul 24 00:06:26 ames vmunix: conn refused ucbarpa.berkeley.edu port 3944
Jul 24 00:09:11 ames vmunix: conn refused rutgers.edu port 3836
Jul 24 00:09:17 ames vmunix: conn refused rutgers.edu port 3836
Jul 24 00:17:55 ames vmunix: conn refused hao.ucar.edu port 3958
Jul 24 00:20:48 ames vmunix: conn refused hao.ucar.edu port 3968
Jul 24 00:21:05 ames vmunix: conn refused ucbarpa.berkeley.edu port 3965
Jul 24 00:24:11 ames vmunix: conn refused ucbarpa.berkeley.edu port 3972
Jul 24 00:49:35 ames vmunix: conn refused xn.ll.mit.edu port 3990
Jul 24 00:49:37 ames vmunix: conn refused xn.ll.mit.edu port 3990
Jul 24 00:49:38 ames vmunix: conn refused xn.ll.mit.edu port 3990
Jul 24 00:49:38 ames vmunix: conn refused xn.ll.mit.edu port 3990
Jul 24 01:03:20 ames vmunix: conn refused hao.ucar.edu port 4001
Jul 24 01:06:06 ames vmunix: conn refused cad.berkeley.edu port 4005
Jul 24 01:06:10 ames vmunix: conn refused cad.berkeley.edu port 4005
Jul 24 01:15:45 ames vmunix: conn refused seismo.css.gov port 4026
Jul 24 01:15:50 ames vmunix: conn refused seismo.css.gov port 4026
Jul 24 01:16:23 ames vmunix: conn refused im4u.utexas.edu port 4014
Jul 24 01:24:39 ames vmunix: conn refused think.com port 4034
Jul 24 01:34:13 ames vmunix: conn refused cs.ucla.edu port 4040
Jul 24 01:34:14 ames last message repeated 5 times
Jul 24 01:38:04 ames vmunix: conn refused hao.ucar.edu port 4047
Jul 24 01:46:36 ames vmunix: conn refused cad.berkeley.edu port 4051
Jul 24 02:06:10 ames vmunix: conn refused hao.ucar.edu port 4069
Jul 24 02:09:58 ames vmunix: conn refused scubed.arpa port 3797
Jul 24 02:19:11 ames vmunix: conn refused think.com port 4083
Jul 24 03:00:57 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:02:27 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:05:27 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:07:42 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:08:27 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:12:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:12:57 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:14:27 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:15:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:18:15 ames vmunix: conn refused think.com port 4119
Jul 24 03:19:42 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:21:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:22:28 ames vmunix: conn refused hao.ucar.edu port 4125
Jul 24 03:22:40 ames vmunix: conn refused hao.ucar.edu port 4127
Jul 24 03:22:42 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:24:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:24:57 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
Jul 24 03:27:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105
----
My question is:  "Why are all these host trying to connect to these ports
on ames?"  Note that the port numbers are the ports to which they are
trying to connect, i.e. someone on ucbarpa could have typed
"telnet ames.arpa 4105" to generate that last message, but I kind of
doubt someone did this that may times at 3 in the morning.
I think all the hosts in this log file run 4BSD UNIX.  Does BSD send
random SYN packets to sites?

	Steve

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25-Jul-87 14:54:45 EDT
From:      mcc@ETN-WLV.EATON.COM (Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong telnet and new line processing

I submitted this previously but probably performed the submission incorrectly.

*************

I don't have a copy of RFC 854; however, I do  have  MIL-STD-1782  which
defines  the implementation requirements for the TELNET Protocol for DDN
MILNET and other DDN subnetworks.  The end of line character is  a  <CR>
which  moves  the  cursor  or print head to the beginning of the current
line.

The standard became confusing when it attempted to  accomodate  physical
terminals that generate a <CR><LF> sequence when the ENTER or RETURN key
is struck.  To permit the use of these terminals a two octet end of line
function  (ELF)  was  defined.  For terminals that could generate a <CR>
and a <LF> independently, the ELF was defined to be  a  <CR><NUL>.   For
those that couldn't, the ELF was defined to be <CR><LF>.

Regardless  of  any echo options that may be in effect, the user (local)
host is responsible for transmitting only the keyboard  input  from  the
terminal  to  the  server  (remote) host.  If the RETURN key generates a
<CR><LF>, it is to be mapped to a <CR><NUL> prior to  transmission  over
the  network.  If the NVT is being operated in its default line buffered
full duplex mode  with  local  echo,  the  user  host  echoes  both  ELF
variations as a <CR><LF> to the terminal display.

At  the  server  host  <CR>,  <CR><NUL>,  and <CR><LF> are to be treated
identically and  mapped  to  the  host's  local  interpretation  of  the
character  or  character  sequence  that  is  passed  to the application
software when the RETURN key is struck.  When  the  virtual  circuit  is
being  operated in half duplex mode with the server echoing data back to
the user, it transmits either a <CR><NUL> or <CR><LF> with the ELF  form
being dependent upon the server's local convention.

The  original  problem  that  raised  the  question of the NVT ELF was a
difference in operation when a terminal (workstation) was connected on a
local  LAN  segment  or  on  a remote LAN segment requiring the use of a
gateway to make the transition between the LAN segments.  The answer  is
that  both  Woologong  and  the  Bridge  CS/1  have  errors or have been
configured incorrectly.

Any host in the network that functions as a gateway is  responsible  for
ensuring  that  the  data  transmitted is the same as what was received.
The sequences <CR><LF> and <CR><NUL><LF> are not necessarily equivalent.
The gateway can not compress the sequence <CR><NUL><LF> to <CR><LF>.

The  problem  I  have  seen  with  a  number of hardware and/or software
products that implement TCP/IP, TELNET, FTP, SMTP, and UDP is  that  the
vendor has based his product on the 4.x bsd implementation.  The problem
with the vendors that have done that is that they have failed to go back
through  the software and remove all the tacit assumptions that the host
system will be running a UNIX or UNIX derivative operating system.  Some
vendors  have  even  removed  code to support the options that are to be
negotiated always responding with a DO  or  WILL  when  they  should  be
responding  with  a DON'T or WON'T because they know that 4.x bsd always
attempts to negotiate to the same mode of operation.

Invariably these products have problems when one attempts to use them on
a  PDP11  or  VAX  based  AN/GYQ-21(V) systems which use the IAS and VMS
operating systems, respectively.

				Merton Campbell Crockett
				AN/GYQ-21(V) Program
				EATON Corporation
				Information Management Systems Division

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25-Jul-87 22:57:36 EDT
From:      hyc@UMIX.CC.UMICH.EDU (Howard Chu)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP for any UNIX on any kind of AT


>Date: Tue, 21 Jul 87 12:38:47 EDT
>From: hedrick@topaz.rutgers.edu
>Subject: Re:  SMTP for any UNIX on any kind of AT
 
>IBM has an implementation of POP 2 for the IBM PC.  It's part of their
>TCP/IP support for the PC.  This is probably as close as you will
>come to SMTP for a PC.
 
Au contraire... Phil Karn has a TCP/IP package which includes SMTP service
that works with MSDOS, and is being ported to Minix. From there, any other
Unix is just a tiny stretch.

Send a message to tcp-group-request@louie.udel.edu for more info...
  -- Howard Chu
	hyc@umix.cc.umich.edu
	seismo!umix!hyc

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 87 09:10:00 CDT
From:      "CALVIN R. GEORGE" <george@eglin-vax.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   SEVERAL copies of message received
Delivery Receipt: NO
E G L I N   A F B
 
                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      26-Jul-1987 08:52am CDT
                                        From:      CALVIN R. GEORGE 
                                                   GEORGE 
                                        Dept:      
                                        Tel No:    882-5498

TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )


Subject: SEVERAL copies of message received

It is not uncommon to receive 2 copies of a message on occasion but 
I know I have read 6 copies of the one from Jim Jensen ( GOULD ) about 
the BSD 4.3 <CR><LF> problem. I have checked our system and am 99% sure it 
is not replicating the messages. Have others seen many copies of this 
message?

Calvin George
Eglin AFB, FL

------
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26-Jul-87 10:10:00 EDT
From:      george@EGLIN-VAX.ARPA ("CALVIN R. GEORGE")
To:        comp.protocols.tcp-ip
Subject:   SEVERAL copies of message received

Delivery Receipt: NO
E G L I N   A F B
 
                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      26-Jul-1987 08:52am CDT
                                        From:      CALVIN R. GEORGE 
                                                   GEORGE 
                                        Dept:      
                                        Tel No:    882-5498

TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )


Subject: SEVERAL copies of message received

It is not uncommon to receive 2 copies of a message on occasion but 
I know I have read 6 copies of the one from Jim Jensen ( GOULD ) about 
the BSD 4.3 <CR><LF> problem. I have checked our system and am 99% sure it 
is not replicating the messages. Have others seen many copies of this 
message?

Calvin George
Eglin AFB, FL

------

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26-Jul-87 14:57:44 EDT
From:      steve@BRL.ARPA (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re:  Name of NIC (was: twg, and nic not knowing its domain name..)

Indeed.  One would hope that the name of the address of "the NIC" would
contain no clue concerning which of the multiple, partially-redundant,
National Research Internet databases (the InterNic) would answer any query.

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26-Jul-87 19:43:07 EDT
From:      leres@ucbarpa.Berkeley.EDU (Craig Leres)
To:        comp.protocols.tcp-ip
Subject:   Re: TWG questions

Dbridge exists because we wanted internet access from VMS system
that only had a point to point interface which DECnet already had
its claws in. But there were other VMS machines on our DECnet that
did have internet access so we devised a way to take advantage of
them. We knew from the start that dbridge would never be a speed
demon; not only is the overhead for DECnet too great, but it
generates lots of system calls and process context switches.

Of course, the minute we got money to buy a DEUNA, we started
running elink. But dbridge served us well until that happened.

		Craig

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26-Jul-87 21:25:46 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Vendors on MILNET

The MIL in MILNET means the Military's operational network.  Hence,
if they want to reliably talk to someone for whatever reason, they
put the on the MILNET rather than risk having to deal with the potentially
broken experimental ARPANET.

-Ron

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26-Jul-87 23:27:13 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Studies in congestion control and preemption

Folks,

As you may know, the NSFNET Backbone network has recently been upgraded to a
fuzzware version that supports selective buffer preemption. In this version an
input buffer is almost always available for an arriving packet. Upon arrival
and inspection for correct format and IP checksum, the (sometimes
considerable) unused space at the end of the buffer is returned to the buffer
pool and the packet inserted on the correct output queue, as determined by the
routing algorithm. A preemption is necessary when an input buffer must be
allocated for the next following packet.

When preemption is necessary, each output queue is scanned separately to find
the customer with the largest number of 512-octet blocks. Then the queue with
the largest number of such blocks is determined and the last buffer for the
associated customer is preempted, even if the buffer preempted was the one
just filled. In case of ties, the queue with the most packets transmitted
since the last preemption is chosen. The entire process is repeated until
sufficient buffer space is available for the input buffer request.

It turns out rusty old soldier linkabit-gw is carrying much more traffic than
it should, for reasonse that are temporary and irrelevant to the discussion
anyway. There is a bottleneck between the inbound 56-Kbps line from ARPANET
and an outbound 7.2-Kbps serial line to U Maryland. There is only about 8K
octets of buffering in this machine, so one would expect preemption to occur
fairly often. One would then be keenly interested in how the selection
strategy operates.

Following is an edited extract from the log file for linkabit-gw covering an
interval of about eight hours on a weekend morning (UT). Each line reveals a
single buffer preemption, the interface it occured on and the interface the
packet came in on. For the purposes here, only the time and IP source address
shown are relevant. The data are arranged chronologically and grouped
according to "events," which evidently consist of traffic surges separated by
at least five seconds. I have reduced the bulk of the data considerably and
deleted, with note, duplicate traps for the same hosts.

The fun thing here is to look at the patterns, trends and so forth in order to
gain some insight on the behavior of various IP/TCP implementations. The data
show 321 packets preempted in 64 surge events during an interval of about 504
minutes. Each surge event consists of from one to 17 preemptions (mean five)
and lasts from one to several seconds (typically two). Thus, about two minutes
of the 504-minute interval represents congestion severe enough to result in
preemption and when this occurs about five packets will be preempted.

There are 18 surge events with two or more traps involving a single host, 13
involving two hosts and eight involving three. There were eight more events
involving from four to six hosts, most of which occur toward the end of the
period when overall network traffic is increasing. Of these 47 events, over a
third apparently involve a single host, which suggests further examination of
its packetization and queueing mechanisms. Host [10.3.0.11]
(SCORE.STANFORD.EDU) seems to be well represented in the data; however, it is
also possible that this host may simply have more traffic than the others
represented here.

I think the data confirms earlier suspicions of many of us that only a few
hosts are causing most of the surge events, whether due to defective
implementations, antisocial queueing policies or simply too much traffic.
Also, note the surges are quite short, in many cases about the same duration
as the round-trip interval between the source and its destination. Clearly,
ICMP Source Quench messages will have little effect in such cases, especially
if the throttling mechanism they operate upon is simply to squeeze the TCP
window.

On the other hand, note that the intervals between successive surges sometimes
is not very large, especially near the end of the period shown, where it
ranges from a few seconds to about thirty seconds. This suggests TCP
window-throttling might have some beneficial effect if its time constant were
comparatively long, like in the order of a minute or more. Since many mail
transfers complete in less time, this means that flow information of this type
must span more than just a single connection and suggests it be recorded as a
state variable in the IP layer and made available on a continuous basis to the
TCP layer.

I'm inserting the actual data last in this message if you want to skip it.

Dave

06:38:07 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
*** 3 deleted
06:38:07 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
06:38:07 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170]
06:38:08 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
*** 5 deleted
06:38:09 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
06:38:09 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170]
06:38:09 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170]
06:38:09 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170]

06:51:50 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
06:51:50 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
06:51:50 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
06:51:50 010 ?TRAP-I-Buffer preemption 002 [26.0.0.74]
06:51:51 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
06:51:51 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
*** 3 deleted
06:51:51 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
06:51:51 010 ?TRAP-I-Buffer preemption 002 [26.0.0.74]
06:51:52 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]

06:58:39 010 ?TRAP-I-Buffer preemption 002 [128.210.1.4]
*** 4 deleted
06:58:40 010 ?TRAP-I-Buffer preemption 002 [128.210.1.4]

07:12:59 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170]
*** 3 deleted
07:13:00 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170]

07:19:51 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]
07:19:53 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]

07:21:57 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
07:21:57 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
07:21:58 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]

07:24:52 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:24:52 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:24:52 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]
07:24:52 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]
07:24:53 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:24:53 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]
07:24:53 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]

07:25:38 014 ?TRAP-I-Buffer preemption 002 [192.5.45.21]
07:25:38 014 ?TRAP-I-Buffer preemption 002 [192.5.45.21]

07:25:45 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:27:03 004 ?TRAP-I-Buffer preemption 012 [128.5.32.1]
07:27:05 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:27:06 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:27:06 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:27:24 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:27:25 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]
*** 2 deleted
07:27:25 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]
07:27:25 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]

07:27:47 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]
07:27:48 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:27:48 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:27:49 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]

07:33:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:33:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:33:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:33:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:33:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:33:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:33:57 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:34:14 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2]

07:34:35 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:35:09 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:35:09 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:35:27 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:35:27 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:35:28 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:35:58 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:35:59 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:35:59 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:36:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:36:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:37:00 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:37:00 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:37:00 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:37:29 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:37:30 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:37:30 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:37:30 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5]
07:37:30 010 ?TRAP-I-Buffer preemption 002 [128.36.0.1]
07:37:30 010 ?TRAP-I-Buffer preemption 002 [128.95.1.4]
07:37:31 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:38:04 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:38:04 010 ?TRAP-I-Buffer preemption 002 [128.95.1.4]

07:39:13 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:39:13 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:40:48 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
*** 2 deleted
07:40:49 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:41:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
07:41:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:41:54 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
*** 3 deleted
07:42:58 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

07:55:11 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
*** 2 deleted
07:55:11 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
07:55:12 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
07:55:12 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
*** 4 deleted
07:55:12 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]

08:30:00 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
*** 2 deleted
08:30:01 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
08:30:01 010 ?TRAP-I-Buffer preemption 002 [26.0.0.21]
08:30:01 010 ?TRAP-I-Buffer preemption 002 [26.0.0.21]

08:34:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

08:46:40 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52]

08:54:03 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]
*** 3 deleted
08:54:04 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11]

09:20:12 010 ?TRAP-I-Buffer preemption 002 [192.5.23.8]

09:24:43 014 ?TRAP-I-Buffer preemption 002 [192.5.8.1]

09:30:52 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
09:30:52 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
09:30:53 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
09:30:53 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
*** 7 deleted
09:30:54 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]

09:44:38 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52]
09:44:38 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52]
09:44:38 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52]
09:44:38 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
09:44:38 010 ?TRAP-I-Buffer preemption 002 [128.105.2.1]
09:44:38 010 ?TRAP-I-Buffer preemption 002 [128.89.0.208]

10:00:14 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52]
10:00:16 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52]
10:00:16 010 ?TRAP-I-Buffer preemption 002 [128.102.2.3]

10:33:12 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
*** 3 deleted
10:33:12 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
10:33:13 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1]
10:33:13 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
*** 3 deleted
10:33:13 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]

11:03:39 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
*** 7 deleted
11:03:40 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
11:03:41 010 ?TRAP-I-Buffer preemption 002 [26.2.0.104]

11:19:41 010 ?TRAP-I-Buffer preemption 002 [128.2.249.105]
*** 4 deleted
11:19:42 010 ?TRAP-I-Buffer preemption 002 [128.2.249.105]

11:43:20 010 ?TRAP-I-Buffer preemption 002 [192.5.23.8]

12:06:11 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
*** 11 deleted
12:06:13 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
12:06:13 010 ?TRAP-I-Buffer preemption 002 [128.46.131.21]
12:06:13 010 ?TRAP-I-Buffer preemption 002 [128.46.131.21]
12:06:14 010 ?TRAP-I-Buffer preemption 002 [128.46.131.21]
12:06:14 010 ?TRAP-I-Buffer preemption 002 [192.12.8.9]

12:38:01 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]
12:38:02 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]

13:32:08 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2]
*** 6 deleted
13:32:09 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2]
13:32:09 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25]

13:33:38 014 ?TRAP-I-Buffer preemption 002 [192.5.8.1]

13:34:44 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25]
13:34:45 010 ?TRAP-I-Buffer preemption 002 [128.20.1.1]
13:34:45 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25]
13:34:45 010 ?TRAP-I-Buffer preemption 002 [192.5.48.3]

13:47:54 010 ?TRAP-I-Buffer preemption 002 [10.7.0.82]
13:47:54 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25]
13:47:55 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22]
13:47:55 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4]
13:47:55 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25]
13:47:55 014 ?TRAP-I-Buffer preemption 002 [192.5.8.5]
13:47:55 014 ?TRAP-I-Buffer preemption 002 [192.5.8.5]

14:41:41 010 ?TRAP-I-Buffer preemption 002 [128.89.0.92]

14:43:09 004 ?TRAP-I-Buffer preemption 012 [128.5.34.1]
14:43:09 014 ?TRAP-I-Buffer preemption 002 [192.12.33.99]

14:43:11 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:43:11 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:43:11 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:43:12 010 ?TRAP-I-Buffer preemption 002 [128.89.0.92]

14:43:33 010 ?TRAP-I-Buffer preemption 002 [128.89.0.92]

14:46:31 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]

14:48:09 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]

14:48:27 010 ?TRAP-I-Buffer preemption 002 [128.97.2.16]
*** 3 deleted
14:48:28 010 ?TRAP-I-Buffer preemption 002 [128.97.2.16]
14:48:28 010 ?TRAP-I-Buffer preemption 002 [128.97.2.16]

14:48:46 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44]
14:48:46 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44]

14:51:08 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:51:09 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44]
*** 2 deleted
14:51:09 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44]
14:51:09 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:51:09 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]
14:51:10 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44]
14:51:10 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44]
14:51:10 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]
14:51:10 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]
14:51:10 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]

14:55:31 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:55:31 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:55:31 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4]
14:55:32 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:55:32 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4]
14:55:32 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:55:32 010 ?TRAP-I-Buffer preemption 002 [18.72.0.205]
14:55:32 010 ?TRAP-I-Buffer preemption 002 [192.12.141.129]

14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:56:05 010 ?TRAP-I-Buffer preemption 002 [10.1.0.96]
14:56:05 010 ?TRAP-I-Buffer preemption 002 [10.1.0.96]
14:56:05 010 ?TRAP-I-Buffer preemption 002 [10.1.0.96]
14:56:05 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22]
14:56:05 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:56:05 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:56:05 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]
14:56:06 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1]

14:56:30 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4]
14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.41.9.3]
14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:56:31 010 ?TRAP-I-Buffer preemption 002 [18.72.0.205]
14:56:32 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]
14:56:32 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]

14:56:52 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:56:53 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22]
14:56:53 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22]
14:56:53 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4]
14:56:53 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4]

14:57:18 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:57:18 010 ?TRAP-I-Buffer preemption 002 [18.63.0.3]
14:57:19 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13]
14:57:19 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22]
14:57:19 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:57:19 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:57:19 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]

14:58:13 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:58:13 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1]
14:58:13 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4]
14:58:13 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4]
14:58:13 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4]
14:58:14 010 ?TRAP-I-Buffer preemption 002 [10.0.0.51]
14:58:14 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4]
14:58:14 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4]
14:58:14 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4]
14:58:15 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]
14:58:15 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5]
14:58:15 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4]

15:02:06 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2]
*** 10 deleted
15:02:08 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2]

15:06:46 010 ?TRAP-I-Buffer preemption 002 [128.110.192.2]

la di da di da

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 02:54:18 EDT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: RLP

Yes, I wrote an RLP server for the FTP Software, Inc. `PC/TCP' package.
I spoke to Mike Acceta when I wrote it, and apparently, we are the only
implementors of it.  It hasn't proved very popular.

One extension we discussed was to add unsolicited <I-Provide> packets for
(non-RLP) servers wishing to advertise their services.  For instance, a
domain name server might send out a periodic broadcast "<who-provides> RLP"
query, then send to the servers from that answer a message "<I-provide>
DOMAIN" reply.

The servers that strictly follow the spec will discard this as being a
bogus packet (and hopefully not crash); a smart server might save this
info and use it later.

I like the protocol.  I'm suprised it hasn't been accepted.  It's
not Clearinghouse, but then it didn't try to be.  When I have some time,
I will do an implementation for 4.3BSD...

It would be really neat if (on UNIX) you didn't need /etc/printcap to
list all the various local printers, but could use RLP to locate a
printer with suitable qualities...  Real Soon Now.

-Philip

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 87 09:45:50 MDT
From:      paclark%ford-cos1.arpa@ford-cos1.arpa (Patricia A. Clark)
To:        ihnp4!homxb!houxm!hjuxa!kp%ucbvax.Berkeley.EDU@ford-cos1.arpa, tcp-ip@sri-nic.ARPA
Subject:   RE: Streams TCP/IP Vendors
t
q
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jul 87 08:48:55 CDT
From:      Manole Calamari <OPRBMVC%TCSVM.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
The latest RFC's can be gotten from LISTSERV@TCSVM.BITNET, note that this is
not an all inclusive collection. If others are not present on the server
Let me know and I will obtain them for the server. To get the List of
files the LISTSERV command
 TELL LISTSERV AT TCSVM GET TCSSERVE FILELIST.
----------
                        Manole Calamari (alias Xenon)
                        BITNET:     OPRBMVC@TCSVM
                        ARPA:       OPRBMVC%TCSVM.BITNET@WISCVM.WISC.EDU
                        Ma Bell:    (504) 865-5631
                        Real Paper: Tulane University
                                    Tulane Computer Services
                                    Attn: Manuel V. Calamari Jr.
                                    6823 St. Charles Ave.
                                    New Orleans,  LA 70118-5698
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 09:48:55 EDT
From:      OPRBMVC@TCSVM.BITNET (Manole Calamari)
To:        comp.protocols.tcp-ip
Subject:   (none)

The latest RFC's can be gotten from LISTSERV@TCSVM.BITNET, note that this is
not an all inclusive collection. If others are not present on the server
Let me know and I will obtain them for the server. To get the List of
files the LISTSERV command
 TELL LISTSERV AT TCSVM GET TCSSERVE FILELIST.
----------
                        Manole Calamari (alias Xenon)
                        BITNET:     OPRBMVC@TCSVM
                        ARPA:       OPRBMVC%TCSVM.BITNET@WISCVM.WISC.EDU
                        Ma Bell:    (504) 865-5631
                        Real Paper: Tulane University
                                    Tulane Computer Services
                                    Attn: Manuel V. Calamari Jr.
                                    6823 St. Charles Ave.
                                    New Orleans,  LA 70118-5698

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 09:58:27 EDT
From:      warren@pluto.UUCP (Warren Burstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for Sys V



I asked my boss to order TCP/IP from Wollongong for a 3B2 and he came
back and told me they stopped selling it because too many people were
ripping it off and they won't sell it until they come up with a way to
keep it from being stolen.

If anyone out there is from Wollongong - I do not use copy protected
software, so I'm not going to buy it when you do figure out what to
do.  Even if you do something harmless, I still will have found
another vendor by the time you get your act together.
-- 
/|/~\~~\    The entire world             Warren Burstein
 |__/__/_/  is a very strange carrot.
 |          But the farmer               philabs!tg!pluto!warren
/           is not afraid at all.        Why doesn't life come with subtitles?

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 10:50:32 EDT
From:      mo@maximo.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   TCP in business

Gee, I can think of lots of them, starting with where
I work, where I used to work and where I worked before
that.  

The best example I know of, however, is at the Bank of Milan
in Italy (Europe - home of ISO, right?) and in all the
systems built by DATAMAT of Rome. DATAMAT is a systems
engineering house who builds systems for business and
the financial community, as well as governmental systems.

Come to think about it, SUN now has a Wall Street sales
office since they are selling SUNs, which use TCP-IP,
to investment firms.

I guess these qualify.

	-Mike O'Dell

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 12:34:50 EDT
From:      leiner@riacs.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Help: TCP/IP for business application

A bit of a strange question, in my opinion.

Fact 1.  Much of what scientists do on a daily basis is use business
functions (e.g. word processing, etc.) and often access remote machines
to do this.

Fact 2.  TCP/IP is the underpinning of much of the scientific networking
environment.

Did you mean, perhaps, "Do people in a business environment (rather than
a scientific or engineering environment) use TCP/IP?"

Barry
----------

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 12:43:24 EDT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Streams TCP/IP

Read the AT&T SVR3 license agreement about SVID (System V Interface
Dovcument) compliance.  That's why STREAMS is the only game in town.
If you sell a UNIX System under the binary licensing provisions of
SVR3, and it has networking, that networking MUST conforn to the SVID
networking extnesions, which include STREAMS as the TLI.  While you
could provide the socket() interface as well, you must provide
STREAMS.

The SVID requirements have caused a lot of UNIX vendors to not upgrade
from SVR2 to SVR3, despite the more attractive binary license pricing.
It makes it very difficult to provide 4.3BSD functionality, since
you've also got to provide SVR3/SVID/SVVS compatability.

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 12:47:59 EDT
From:      braden@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  How do you break up a B class number?


I'd like to understand the reason that you feel the need to split
a class B network into different-sized subnets.  What happens if
you stick to a single subnet size?  

Although some of the comments in reply to your message have been somewhat
overblown, the fact is that the technical mechanism to handle
different-sized subnets of the same network is not generally available
today.  It may require carrying a 32-bit subnet mask along with each IP
(sub-)network address in whatever IGP is used within the subnetted
network.  The only current IGP which does carry such a mask is Dave
Mills' Hello protocol used in the Fuzzballs; however, you could probably
hack the BSD routing table and daemon to do so.  If you are not in a
position to roll your own IGP in this fashion, you had better stick to a
single subnet mask.


Bob Braden

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 13:13:19 EDT
From:      Okuno@SUMEX-AIM.STANFORD.EDU (Hiroshi "Gitchang" Okuno)
To:        comp.protocols.tcp-ip
Subject:   Re: Help: TCP/IP for business application

Barry,

 > Did you mean, perhaps, "Do people in a business environment (rather than
 > a scientific or engineering environment) use TCP/IP?"

I want to know whether TCP/IP is used in applications such as banking
system, car registration system, information retrieval system or other
database management system (centralized or distributed).

The ARPA Internet, X25Net of CSNET, and NSFNet use TCP/IP but support
only Telnet, FTP, SMTP or Finger.  Some campus networks support
network window or network file systems.  Whois may be a kind of
network database retrieval system.  However, I don't know other higher
level or large-scale applications.

Mike O'dell, maximo!mo@seismo.CSS.GOV, told me that the system for the
Bank of Milan in Italy was the best example.  Is there any example in
this country?

Regards,

- Gitchang -
-------

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 13:37:02 EDT
From:      ejc@TSCA.ISTC.SRI.COM
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP question


This will likely lead to yet another tangent and should be continued on
the MM Mail list, but it isn't true that NOBIDY FOLLOWS THE
SPECIFICATION for MM Mail.  There was a report written by SRI in 1983
defining the consensus (among DoD researchers) specification for
standardized MM Mail exchange at that time.  The BBN Diamond, ISI MMM,
and SRI MMM systems all conformed to that spec (and also, I believe,
Dave Mills' Fuzzballs could read MM msgs).  A RFP was to be generated,
and more development was to be undertaken, especially in the area of
graphics exchange.  

BBN decided to change the DIAMOND exchange formats to support new
capabilities they were developing, and as a result, they were no longer
compatible with the other (still operational) systems.  SRI, in turn,
has been funded to develop systems that handle digitized images (maps)
with dynamically changing graphic overlays.  One might argue that these
enhancements should have been discussed and a common exchange protocol
agreed to by the "whole community", but the truth is, minimal funding
is being provided for that.  One observation that is given to support
the cutback in funds is that there aren't any remaining research
issues.  But, one only has to look at the subject headers on this
mailing list (the details quickly become boggling) to see that there
are many unresolved issues in information exchange in our current
systems (not even addressing enhanced system capabilities) and that a
much better framework is needed.

So, in summary, there still are "compatible" MM Mail systems, they
clearly need upgrading to support new capabilities, DIAMOND is
developing such capabilites but common exchange protocols need to be
re-established in order to leverage all the on-going research in these
areas.  

Earl

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 13:42:49 EDT
From:      kurt@hi.UUCP (Kurt Zeilenga)
To:        comp.protocols.tcp-ip
Subject:   Re:  How do you break up a B class number?

Brandon@isi.edu writes:
> I'd like to understand the reason that you feel the need to split
> a class B network into different-sized subnets.  What happens if
> you stick to a single subnet size?  

The reasons why we would like to split the B into
different-sized subnets is simple.  Address space.  Right
now we are projecting to have over 1k hosts on our main
ethernet (actually a combination of thin and fat wires
connected together using repeaters and smart bridges, like
DEC's LAN 100 bridge).  We also have many subnet that are
being installed.  Some of which are very small.  To
accomadate the main cable we would have to use a mask like
0xfffff800.  This means we have split our B into 32 subnets
each of 2k hosts (minus all ones and all zeros, of
course).  Anyway, 32 subnets will probably not be enough.
Most (if not all) of our subnets will be gatewayed directly
to the main ethernet (so subnetting the subnet won't really
come into the problem)

> Although some of the comments in reply to your message have been somewhat
> overblown, the fact is that the technical mechanism to handle
> different-sized subnets of the same network is not generally available
> today.  It may require carrying a 32-bit subnet mask along with each IP
> (sub-)network address in whatever IGP is used within the subnetted
> network.  The only current IGP which does carry such a mask is Dave
> Mills' Hello protocol used in the Fuzzballs; however, you could probably
> hack the BSD routing table and daemon to do so.  If you are not in a
> position to roll your own IGP in this fashion, you had better stick to a
> single subnet mask.
 
We are not planning to do any hacking.  Since there is no
real software solution at this time (unless you hack),
maybe a hardware solution is in order.  Anyone know of
where we could pick up a few "smart bridges" real cheap?

> Bob Braden

	- Kurt (zeilenga@hc.dspo.gov)

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 16:49:03 EDT
From:      bobj@KAUAI.MCL.UNISYS.COM (Bobj Jones)
To:        comp.protocols.tcp-ip
Subject:   DoD Certification of TCP and IP


For those who are interested, the DCA is setting up an administrative
agreement with the National Bureau of Standards to provide for the
certification of the TCP/IP suite of protocols.  NBS is expected to
announce for vendors to participate under the National Voluntary
Laboratory Accreditation Program (NVLAP).  This program is expected
to be in place sometime in early 1988.  Any questions please call
DCEC, Jim Tontonoz, 703-437-2038.

Bob

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 21:25:00 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   [Lawrence J. Kaufman:  Re: Wollongong telnet and new line processing]

Larry,

See the delightful little book "Cotswold Privies" by Mollie Harris and Sue
Chapman (Hogarth Press, London 1984) for a full, complete and satisfying
definition of the word. In sweet, a gongfermer is the poor (but well-paid)
lad who cleaned out the privies in yesteryesteryear. Any similarity, functional
or otherwise, to departmental of industrial institutions is stoutly denied.

Why did I use this wonderful 15th-century word? Because I hoped to get a message
like yours.

Dave

----- Forwarded message # 1:

Received: from Louie.UDEL.EDU by Huey.UDEL.EDU id aa05649; 27 Jul 87 14:25 EDT
Received: from bbncc-eur.arpa by Louie.UDEL.EDU id a010057; 27 Jul 87 11:23 EDT
Date: Mon, 27 Jul 87 17:02:50 GMT+0100
From: "Lawrence J. Kaufman" <lkaufman@bbncc-eur.arpa>
Subject: Re:  Wollongong telnet and new line processing
In-Reply-To: Your message of Tue, 21 Jul 87 22:03:44 EDT
To: Mills@louie.udel.edu
Cc: lkaufman@bbncc-eur.arpa
Message-ID:  <8707271123.a010057@Louie.UDEL.EDU>

Dave,

Would you please explain gongfermer to a poor city boy?  What does a
privy farmer do and why are you using a 15th century word?

--- Larry Kaufman
    lkaufman@bbn.com
    now in Germany, moving to Maryland in the next week or so.


----- End of forwarded messages

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Jul-87 22:22:12 EDT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Follow-on to my "Re: IBM TCP/IP" msg.

In further discussion of IBM's non-standard approach to ARP and routing
on 802.5, someone else pointed out that there is little chance that their
source-routing and RIF fields will ever work through a MAC-level bridge
between Ether and Token-Ring.  Hi ho.  I wonder if they care?

jbvb

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 00:15:09 EDT
From:      monkey@unixprt.UUCP (Monkey Face@unixprt)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

I'm not sure that this is worth it, but what the heck...
In article <24072@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
> > The primary advantage, for those using ATT based UNIX, is that this is the
> > only 'real' facility provided in UNIX System V to support networking.
> Gee...people at Berkeley have been using an "AT&T-based UNIX"...
> that supports networking without STREAMS.  Plenty of other
> people have dropped the socket code into System V kernels...
> Berkeley dropped it into a 32V-derived kernel, so STREAMS are not
> "the only game in town".
I only meant that STREAMS is what you get with the current versions from
ATT, without the cost of re-porting to each new AT&T release, you 
don't get sockets or anything else.  A vendor that must rely on ATT
to provide a base, a strategy based on sockets does not seem appropriate
in the long term.
> > ATT's Transport Interface is mostly base on the ISO transport interface,
> > therefore should map to the emerging interface standards.
> Unfortunately, the TLI also has a number of warts...it keeps some state 
> both in userland and in the kernel...after a "fork"/"exec" you 
> have to issue a "t_sync" call to...(get)... kernel's...state into userland.
> 	Guy Harris
So what?  Warts can be removed, if deemed necessary.
My response to a question someone asked was not meant to support or
criticize STREAMS or the Socket implementation in 4.x based systems.
I was only offering my opinion based on experience with STREAMS.  I have
also ported the socket code the System V version of UNIX and think that
sockets are a very good base for network implementation.
How tall is Guy Harris anyway?

Monkey Face - uni-xperts

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 07:09:00 EDT
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.")
To:        comp.protocols.tcp-ip
Subject:   adversity or perversity


     Hi!

     I have a problem and I'm not sure I believe what I see.

     I have an ethernet with disparate tcp's around on it.  We have bsd 
4.3, Symbolics, Sun release 3.2, Micom np100 board running tcp among
others.  I'm in the middle of changing network numbers.  Now, networks
on the same ethernet won't talk to each other.  It seems as if IP wants
to have one network number per ethernet.  I really don't see why this
should be so. 

     Is this the way of IP?  Does it really want one network number per
ethernet?  Is there an RFC that says this should be so?  If so then 
which one so I can go look?  If it isn't IP is it the the perversity of 
ethernet interface manufacturers?

USnail:
          Chris Johnson
          Academic Computer Services
          Northeastern University 39RI
          360 Huntington Ave.
          Boston, MA. U.S.A. 02115
AT&T:     (617) 437-2335
CSNET:    johnson@nuhub.acs.northeastern.edu
ARPANET:  johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET:   johnson%nuhub.acs.northeastern.edu@csnet-relay

(Always vote.  There may not be anything you want to vote for, but
 there might be something you want to vote against.)

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 87 07:09 EDT
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   adversity or perversity
     Hi!

     I have a problem and I'm not sure I believe what I see.

     I have an ethernet with disparate tcp's around on it.  We have bsd 
4.3, Symbolics, Sun release 3.2, Micom np100 board running tcp among
others.  I'm in the middle of changing network numbers.  Now, networks
on the same ethernet won't talk to each other.  It seems as if IP wants
to have one network number per ethernet.  I really don't see why this
should be so. 

     Is this the way of IP?  Does it really want one network number per
ethernet?  Is there an RFC that says this should be so?  If so then 
which one so I can go look?  If it isn't IP is it the the perversity of 
ethernet interface manufacturers?

USnail:
          Chris Johnson
          Academic Computer Services
          Northeastern University 39RI
          360 Huntington Ave.
          Boston, MA. U.S.A. 02115
AT&T:     (617) 437-2335
CSNET:    johnson@nuhub.acs.northeastern.edu
ARPANET:  johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET:   johnson%nuhub.acs.northeastern.edu@csnet-relay

(Always vote.  There may not be anything you want to vote for, but
 there might be something you want to vote against.)

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 08:14:54 EDT
From:      jjensen@atlas.UUCP (Jim Jensen)
To:        comp.protocols.tcp-ip
Subject:   Re: SEVERAL copies of message received

in article <8707261432.AA26072@ucbvax.Berkeley.EDU>, george@EGLIN-VAX.ARPA ("CALVIN R. GEORGE") says:
> I know I have read 6 copies of the one from Jim Jensen ( GOULD ) about 
> the BSD 4.3 <CR><LF> problem.
> 
> Calvin George
> Eglin AFB, FL

Sorry about that.

I posted the article, and got an error message.  I then had show this to someone
who knew about news.  Then someone else.  then with a different news program,
and so on.  The next time I read news there were all the articles.  I was 
kind of hoping that only the last one with no error messege got out. Oh well.

                                              Jim Jensen
					      Gould inc. CSD 
					      6901 West Sunrise Boulevard
					      Ft. Lauderdale Fl 33313-4499
					      (305) 587-2900

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 09:32:28 EDT
From:      A024012@RUTVM1.BITNET (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: Does IBM TCP/IP Source Route?

I posted a copy of Bill Westfield's question to IBMTCP-L@CUNYVM.BITNET,
which discusses IBM's new TCP/IP for VM/SP program (IBM program #5798-FAL,
not to be confused with WiscNet (5798-DRG)). It elicited two reponses,
one from Jay Elinsky at IBM's Watson Research Center, and one from John
Shriver at Proteon. Both are enclosed below.

Ross Patterson
Rutgers University
------------------ Start of included file TCPIP    REPLIES     -----------------
Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1161;
          Mon, 27 Jul 87 17:47:57 EDT
Received: by CUNYVM (Mailer X1.23b) id 8954; Mon, 27 Jul 87 17:47:06 EDT
Date:         Monday, 27 Jul 1987 17:39:33 EDT
Reply-To:     IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
Sender:       IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
From:         Jay Elinsky <ELINSKY@YKTVMX>
Subject:      Does IBM TCP/IP source route all its packets?
To:           Ross Patterson <A024012@RUTVM1>

If he's referring to the IP source routing options e.g. strict
source routing, the answer is No.  On Token Ring, we use Token
Ring source routing for packets that must pass through bridges.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY
---------------------------
Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1245;
          Mon, 27 Jul 87 19:10:26 EDT
Received: by CUNYVM (Mailer X1.23b) id 3703; Mon, 27 Jul 87 19:08:54 EDT
Date:         Mon, 27 Jul 87 18:58:50 EDT
Reply-To:     IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
Sender:       IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
X-To:         IBMTCP-L%CUNYVM.BITNET@WISCVM.WISC.EDU
From:         "John A. Shriver" <JAS@MONK.PROTEON.COM>
Subject:      Re: Does IBM TCP/IP source route all its packets?
To:           Ross Patterson <A024012@RUTVM1>
In-Reply-To:  Jay Elinsky's message of Monday,
              27 Jul 1987 17:39:33 EDT <8707272226.AA25652@monk.proteon.com>

Yes, it indeed source routes.

A bit of background on how the 802.2 class 2 does it's source routing.

When opening a connection, the first thing done in 802.2 is to swap
XID (exchange ID) packets, to see that you both speak class 2.  The
calling interface sends the XID to the called address as a normal
packet.  If it does not get "address recognized" in the frame status
byte after some number of tries, it decides the called host is
off-ring.  It then modifies the XID packet to set the U bit of the
source address (I call this "bridge-me"), and to include an empty
routing information field (RIF) with the broadcast (all rings) bit
set.  Each bridge will add it's entry to the RIF.  The called party
will receive the XID, and will (1) store the source route in the
connection block, (2) clear the broadcast bit in the RIF, (3) flip the
direction bit in the RIF, and (4) update the XID information and send
the packet back.  The caller will receive the reply XID, and store
that source route in the connection block.

The IBM and TI 802.2 software does not offer this convenience for
class 1 operations.  Probably the main reason is that there is no
connection block to store the data in.  This does not bother the
architects of source routing, since all IBM applications (except
TCP/IP) use class 2.  The network layer is repsonsible for developing
and providing RIF fields.

However, since TCP/IP uses ARP to find addresses, there is a
convenient broadcast packet to use to thread bridges.  You just send
the ARP as a "all rings" broadcast, setting the "bridge-me" bit and
the broadcast bit in the RIF.

This does not make for a standard ARP implementation.  You've got to
add an entry to the data blocks for the RIF, as well as the hadrware
address, for each protocol (IP) address.  You've also got to extend
the calling interface into the datalink, but only for 802.5.  This is
not clean when you are trying to use the same code to support multiple
datalinks or network protocols at the same time.

The details of what IBM did for ARP/source routing in each TCP/IP
vary.  In the PC version, they do not try and do a "this ring only"
broadcast before doing an "all rings" braodcast.  (This is due to the
way PC/IP does ARP without a seperate ARP task).  Thus it cannot make a
connection with an implementation that does not source route.  Other
versions have a switch to turn on source routing (eg AIX?).  It would
be nice if all versions tried without RIF first, looking for addresses
recognized, to talk to other versions that don't do RIFs.  Only if
they don't get address recognized would they start trying to
source-route via ARP.

Another thought:  one way to make this clean would be to switch to a
special ARP hardware type just for 802.5, and put the RIF in as part
the hardware address.  This would make code a lot cleaner, since 802.2
also has to support non-source-route LANs, like 802.3 and 802.4.

------------------ End   of included file TCPIP    REPLIES     -----------------

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jul 87 09:32:28 EDT
From:      Ross Patterson <A024012%RUTVM1.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Does IBM TCP/IP Source Route?
I posted a copy of Bill Westfield's question to IBMTCP-L@CUNYVM.BITNET,
which discusses IBM's new TCP/IP for VM/SP program (IBM program #5798-FAL,
not to be confused with WiscNet (5798-DRG)). It elicited two reponses,
one from Jay Elinsky at IBM's Watson Research Center, and one from John
Shriver at Proteon. Both are enclosed below.

Ross Patterson
Rutgers University
------------------ Start of included file TCPIP    REPLIES     -----------------
Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1161;
          Mon, 27 Jul 87 17:47:57 EDT
Received: by CUNYVM (Mailer X1.23b) id 8954; Mon, 27 Jul 87 17:47:06 EDT
Date:         Monday, 27 Jul 1987 17:39:33 EDT
Reply-To:     IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
Sender:       IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
From:         Jay Elinsky <ELINSKY@YKTVMX>
Subject:      Does IBM TCP/IP source route all its packets?
To:           Ross Patterson <A024012@RUTVM1>

If he's referring to the IP source routing options e.g. strict
source routing, the answer is No.  On Token Ring, we use Token
Ring source routing for packets that must pass through bridges.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY
---------------------------
Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1245;
          Mon, 27 Jul 87 19:10:26 EDT
Received: by CUNYVM (Mailer X1.23b) id 3703; Mon, 27 Jul 87 19:08:54 EDT
Date:         Mon, 27 Jul 87 18:58:50 EDT
Reply-To:     IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
Sender:       IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
X-To:         IBMTCP-L%CUNYVM.BITNET@WISCVM.WISC.EDU
From:         "John A. Shriver" <JAS@MONK.PROTEON.COM>
Subject:      Re: Does IBM TCP/IP source route all its packets?
To:           Ross Patterson <A024012@RUTVM1>
In-Reply-To:  Jay Elinsky's message of Monday,
              27 Jul 1987 17:39:33 EDT <8707272226.AA25652@monk.proteon.com>

Yes, it indeed source routes.

A bit of background on how the 802.2 class 2 does it's source routing.

When opening a connection, the first thing done in 802.2 is to swap
XID (exchange ID) packets, to see that you both speak class 2.  The
calling interface sends the XID to the called address as a normal
packet.  If it does not get "address recognized" in the frame status
byte after some number of tries, it decides the called host is
off-ring.  It then modifies the XID packet to set the U bit of the
source address (I call this "bridge-me"), and to include an empty
routing information field (RIF) with the broadcast (all rings) bit
set.  Each bridge will add it's entry to the RIF.  The called party
will receive the XID, and will (1) store the source route in the
connection block, (2) clear the broadcast bit in the RIF, (3) flip the
direction bit in the RIF, and (4) update the XID information and send
the packet back.  The caller will receive the reply XID, and store
that source route in the connection block.

The IBM and TI 802.2 software does not offer this convenience for
class 1 operations.  Probably the main reason is that there is no
connection block to store the data in.  This does not bother the
architects of source routing, since all IBM applications (except
TCP/IP) use class 2.  The network layer is repsonsible for developing
and providing RIF fields.

However, since TCP/IP uses ARP to find addresses, there is a
convenient broadcast packet to use to thread bridges.  You just send
the ARP as a "all rings" broadcast, setting the "bridge-me" bit and
the broadcast bit in the RIF.

This does not make for a standard ARP implementation.  You've got to
add an entry to the data blocks for the RIF, as well as the hadrware
address, for each protocol (IP) address.  You've also got to extend
the calling interface into the datalink, but only for 802.5.  This is
not clean when you are trying to use the same code to support multiple
datalinks or network protocols at the same time.

The details of what IBM did for ARP/source routing in each TCP/IP
vary.  In the PC version, they do not try and do a "this ring only"
broadcast before doing an "all rings" braodcast.  (This is due to the
way PC/IP does ARP without a seperate ARP task).  Thus it cannot make a
connection with an implementation that does not source route.  Other
versions have a switch to turn on source routing (eg AIX?).  It would
be nice if all versions tried without RIF first, looking for addresses
recognized, to talk to other versions that don't do RIFs.  Only if
they don't get address recognized would they start trying to
source-route via ARP.

Another thought:  one way to make this clean would be to switch to a
special ARP hardware type just for 802.5, and put the RIF in as part
the hardware address.  This would make code a lot cleaner, since 802.2
also has to support non-source-route LANs, like 802.3 and 802.4.

------------------ End   of included file TCPIP    REPLIES     -----------------
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 1987 11:11:08 EST
From:      Dale.Moore@PS1.CS.CMU.EDU
To:        Info-vax@KL.SRI.COM,   Tektcp@HAMLET.CALTECH.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   CMU-TEK Announcement
A few simple questions....

	Are you looking for a well integrated IP/TCP on VMS?

	Are you tired of paying your annual salary per machine for
	networking software you use one hour a day?  

	Are you despondent over not having the sources to make the simple
	changes necessary to fix relatively minor problems?

If you answered yes to all the above, then have we got something for you.
It's not swamp land in Florida, nor is it prime gold fields in Alaska.
It's CMU-TEK IP/TCP for VMS.

For only $0 (thats Z-E-R-O dollars) you get

    - Common network utilities such as Telnet, FTP and Finger.
    - Domain network name resolver.
    - A mail generation and sending program.
    - Network servers for Telnet, FTP, SMTP and Finger.
    - An ACP process and device driver that implements IP, ICMP, TCP
      and as an extra special bonus UDP.
    - Subnets and packet reassembly.
    - Sources to utilities. Sources to documentation.  Sources to
      everything above that we can write on a tape.

What you don't get

    - Large monthly installment payment plan
    - Heavy Liscensing restrictions.  This is available to anyone,
      profit or nonprofit on any VAX processor.  Soon we will be able
      to send this to all 'reasonable' countries.
    - A big corporation with a three character name abbreviation.
    - 24 Hour telephone hotline support.  As a matter of fact, you get
      very little support.
    - User training seminars.  You'll have to find some other reason to
      get a free Road-Trip out of your employer.
    - Warranties.  No warranties expressed or implied.
    - VMS, BLISS or SCRIBE.  To recompile the sources and documentation,
      these necessary tools are not provided.

All of this, and VMSINSTAL compatible.

Some of you maybe skeptical.  Perhaps you think that this is only a minor
change over what is available from Tektronix.  Things do change, and now
they've changed for the better.

Some of you have refered to this as the CMU `enhanced' Tektronix code.
When you put flowers in the flower box outside your window, you enhance
the building.  When rip out and replace the plumbing, heating, electric
and replaster and repaint all the walls, and put on new siding, insulation
and roofing you've rebuilt.

It is no longer necessary to obtain a liscense from Tektronix to run the
CMU software.

To get a copy, send a US Postal Snail Mail letter to

	CMU-TEK IP/TCP Software Request
	Computation Center
	Carnegie Mellon University
	4910 Forbes Av.
	Pittsburgh, PA 15213

No warranties expressed or implied.  Postage and Handling may be extra.
Lifetime of offer limited.  All rights reserved.  Hey, I mean it!  We
don't mind giving the stuff away, but we don't want it stolen!

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 10:17:36 EDT
From:      mw3s+@ANDREW.CMU.EDU (Martin Weiss)
To:        comp.protocols.tcp-ip
Subject:   Streams

A recent article in either Business Communications Review or Data
Communications discusses STREAMS and Streams.  It compares the communications
facilities for both Unix System V and BSD.

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 11:21:38 EDT
From:      eric@hippo.UUCP (Eric Bergan)
To:        comp.protocols.tcp-ip
Subject:   Re: Help: TCP/IP for business application

In article <12321742542.23.OKUNO@SUMEX-AIM.STANFORD.EDU>, Okuno@SUMEX-AIM.STANFORD.EDU (Hiroshi "Gitchang" Okuno) writes:
> I want to know whether TCP/IP is used in applications such as banking
> system, car registration system, information retrieval system or other
> database management system (centralized or distributed).

	At Johns Hopkins Hospital, we used TCP/IP to implement a wide
range of distributed database applications, including patient identification,
scheduling, radiology film tracking, radiology report transcription and
retrieval, etc. For all of the distributed pieces, we used Sun's RPC
protocol.

-- 

					eric
					...!ptsfa!hippo!eric

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 12:11:08 EDT
From:      Dale.Moore@PS1.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   CMU-TEK Announcement

A few simple questions....

	Are you looking for a well integrated IP/TCP on VMS?

	Are you tired of paying your annual salary per machine for
	networking software you use one hour a day?  

	Are you despondent over not having the sources to make the simple
	changes necessary to fix relatively minor problems?

If you answered yes to all the above, then have we got something for you.
It's not swamp land in Florida, nor is it prime gold fields in Alaska.
It's CMU-TEK IP/TCP for VMS.

For only $0 (thats Z-E-R-O dollars) you get

    - Common network utilities such as Telnet, FTP and Finger.
    - Domain network name resolver.
    - A mail generation and sending program.
    - Network servers for Telnet, FTP, SMTP and Finger.
    - An ACP process and device driver that implements IP, ICMP, TCP
      and as an extra special bonus UDP.
    - Subnets and packet reassembly.
    - Sources to utilities. Sources to documentation.  Sources to
      everything above that we can write on a tape.

What you don't get

    - Large monthly installment payment plan
    - Heavy Liscensing restrictions.  This is available to anyone,
      profit or nonprofit on any VAX processor.  Soon we will be able
      to send this to all 'reasonable' countries.
    - A big corporation with a three character name abbreviation.
    - 24 Hour telephone hotline support.  As a matter of fact, you get
      very little support.
    - User training seminars.  You'll have to find some other reason to
      get a free Road-Trip out of your employer.
    - Warranties.  No warranties expressed or implied.
    - VMS, BLISS or SCRIBE.  To recompile the sources and documentation,
      these necessary tools are not provided.

All of this, and VMSINSTAL compatible.

Some of you maybe skeptical.  Perhaps you think that this is only a minor
change over what is available from Tektronix.  Things do change, and now
they've changed for the better.

Some of you have refered to this as the CMU `enhanced' Tektronix code.
When you put flowers in the flower box outside your window, you enhance
the building.  When rip out and replace the plumbing, heating, electric
and replaster and repaint all the walls, and put on new siding, insulation
and roofing you've rebuilt.

It is no longer necessary to obtain a liscense from Tektronix to run the
CMU software.

To get a copy, send a US Postal Snail Mail letter to

	CMU-TEK IP/TCP Software Request
	Computation Center
	Carnegie Mellon University
	4910 Forbes Av.
	Pittsburgh, PA 15213

No warranties expressed or implied.  Postage and Handling may be extra.
Lifetime of offer limited.  All rights reserved.  Hey, I mean it!  We
don't mind giving the stuff away, but we don't want it stolen!

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 12:36:54 EDT
From:      kurt@hi.UUCP (Kurt Zeilenga)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Multiple netmasks

Keywords:


At present, if you want to break up a network into
different size subnets there is really no way of doing it.
Hence, I would like to (re)start a discussion on ways of
implementing multiple masks for said purpose.

How does the system know wether a given address is an A, B,
or C Class address?  It looks at magic bits that are
hardcoded! It would be really nice to be able to
softcode some bits.  Hence, every network could have a
subnetmask.  The subnetmask is used to mask out n bits of
the IP address.  Those n bits are then used to lookup what
netmask to use.

Consider Host A:
/etc/ifconfig ie0 0xXXXXf001 subnetmask 0x0000c000 up
/etc/ifconfig ie1 0xXXXX0081 subnetmask 0x0000c000 up

and Host B:
/etc/ifconfig ie0 0xXXXXf002 subnetmask 0x0000c000 up
/etc/ifconfig ie1 0xXXXX8101 subnetmask 0x0000c000 up

and in /etc/subnets (or wherever) there are three fields.
Network, Subnet, Mask.  This so that if you have a
gateway between to different networks each doing subnetmasking.

0xXXXX0000	0x0000c000	0xfffff000
0xXXXX0000	0x00008000	0xffffff00
0xXXXX0000	0x00004000	0xffffff80
0xXXXX0000	0x00000000	0xffffffc0

Okay, say host A gets a packet off of ie1.  The packet
is for IP address 0xXXXX8102.  We mask the address with
the subnetmask and get 0x00008000, lookup the netmask and
get 0xffffff00.  Using it we figure out that we need to
send this to host 2 on network 0xXXXX8100.  We look in the
routing table and see that we ahve a rout to 0xXXXX8100 via
0xXXXXf002, we send the packet off.....
	
Of course there are problems with this idea, but it's a
start.  Any comments?

-- 
	Kurt Zeilenga	 (zeilenga@hc.dspo.gov)		I want my talk.flame!

	"Remember, Mommie, I'm off to get a commie..."

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 87 18:22:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Re: Streams TCP/IP

>Would someone please post a summary of reasons why use of Streams is
>an advantage.  Is this just another sales-hype buzzword?  or is there
>a reason Streams is better?  than sockets?  than psudo-sockets? or
>select?  Does the end user see any advantage?  faster response?  less
>CPU waste?  what?  Does anyone have some before & after figures on
>drivers that were converted to Streams?  Please share them with us.

Lets not compare apples and oranges here.

STREAMs is an architectural feature of the System V Rel 3 UNIX kernel.
STREAMs are to the kernel what pipes are to users, allowing various
kernel components to connected in useful configurations.  This is the
base used for kernel resident communications support in Sys V Rel 3.
Sockets in the Berkeley UNIX world can mean a couple of things, the
socket systems calls or the architecture of the kernel resident protocol
implementations.  In my opinion, the STREAMs mechanism is a much
cleaner way to implement things like communications protocols in the
kernel (but there are some limitations).  The user interface to streams
can be nearly anything you could want, but normally is via the
Transport Level Interface (TLI) which is a stream module which is intended
to present a standard transport service interface to users.  Most of
the TCP/IP implementations that I have seen for STREAMs provide the
socket interface, either via new systems calls or via an interface
emulation library.  As far as performance, I would suspect that a
STREAMs implementation would be at least as fast as functionally
equivalent code in the Berkeley kernel.

					Art Berggreen
					art@acc.arpa


------
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 14:41:58 EDT
From:      lars@ACC-SB-UNIX.ARPA (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   (none)

Date: Tue, 28 Jul 87 11:12:16 PDT
From: lars (Lars Poulsen)
To: hank%barilvm.BITNET@WISCVM.ARPA
Subject: ACC Customer Service Network Address
Cc: tcp-ip@sri-nic.arpa

ACC's Customer Service is reachable as follows:
(1) By email: service@acc-sb-unix.arpa
(2) By phone: (800) 222-7308 (Not from CA, AK, HI and foreign countries)
              (805) 963-9431 (From anywhere)
(3) By FAX:   (805) 966-9725
(4) By TWX:    910  334-4907

This in response to Hank Nussbacher's message of July 23, 1987.
Sorry, we are sometimes behind on reading "news".

/ Lars Poulsen, ACC Customer Service - Support

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 14:59:11 EDT
From:      guy%gorodish@Sun.COM (Guy Harris)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

I won't bother replying to the whiny little question at the end, but
I will point out a couple of things:

> I only meant that STREAMS is what you get with the current versions from
> ATT, without the cost of re-porting to each new AT&T release, you 
> don't get sockets or anything else.  A vendor that must rely on ATT
> to provide a base, a strategy based on sockets does not seem appropriate
> in the long term.

That depends on several things.  First, it depends on whether the
vendor wants to continue to depend on AT&T to provide a base, especially
given the S5R3 licensing agreement.  Second, it depends on whether
they want to re-port the rest of what they've done to S5R3.

Yes, STREAMS comes "for free" with S5R3.  This is not necessarily
sufficient to make it the best way to go.  Unisoft, I believe, offers
a socket implementation as part of their S5 ports.

> So what?  Warts can be removed, if deemed necessary.

It is not necessarily that easy.  The TLI uses the state information
that is kept in userland; it might have to be redesigned to remove
this particular wart.

It is not a given that the TLI will be the interface used for future
protocol implementations; a socket-based ISO implementation (which
may require changes to the socket interface) or some completely
different C-language binding of network operations may end up being
dominant.

> My response to a question someone asked was not meant to support or
> criticize STREAMS or the Socket implementation in 4.x based systems.

My response wasn't meant to do that either; it was meant to point out
the other side of various issues.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
*!
AFN"("(". 

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 15:18:42 EDT
From:      guy%gorodish@Sun.COM (Guy Harris)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

>   There is interest in streams for several reasons.
> 	1) It looks elegant.

However, in practice there are some rather inelegant parts.  Doing an
"ioctl" on a stream, for example, is a pain in the neck, as a streams
module or driver is notified of the "ioctl" by receiving a message,
and it must construct a reply message in order to respond to the
"ioctl".

Since streams modules and drivers do not necessarily run in the
context of a process, even when servicing a request made in a process
(e.g., a "write" or an "ioctl"), they cannot block; thus, if a memory
allocation fails, you have to go through some amount of contortions
to retry the allocation if it's important to do so.  Were STREAMS to
be implemented on top of a kernel that supported "lightweight
processes", one could guarantee that streams modules and drivers ran
in the context of a thread of control that could safely block, which
would considerably simplify this.

The read side of a stream is driven by pressure from the bottom;
there is little a streams module or driver can do in response to a
"read".  This may be a problem for some uses of STREAMS.

If you want a STREAMS-based terminal driver, there will be some
problems with sharing a single pool of buffer resources between the
networking code and the terminal driver; it makes it more likely that
networking operations will exhaust these resources.  (RSX-11 users
may remember that - at least in some versions, they may have fixed
this later - a process that consumed all of pool space, or just
sufficient pool space as to prevent the tty driver from doing a read,
could hang the system fairly thoroughly.)  This is not an insuperable
problem, but it means you have to be careful.

When writing a streams module or driver, there is often a lot of
"bureaucratic" code that has to be added to handle various message
types, to construct messages, etc.; don't assume things are going to
get smaller if you go to STREAMS.

> 	2) It comes from an acknowleged Unix expert.

The concept is the same in Dennis Ritchie's version and in the S5R3
version, but some of the details are different.  I believe the S5R3
version is bigger and more complicated.

> 	3) It *looks* (emphais added) more general than sockets.

Since it imposes less structure, it is.  Sockets correspond roughly
to streams+TLI.

> 	4) It allows a structured decomposition of some of the
>   	   hot-spots in Unix (terminal handling, protocols)	
>  	   into subparts which can be placed on a front-end
> 	   processor.

Probably true, although this depends on what the streams modules that
implement a given function are.  It may be that the decomposition
that makes the most architectural sense isn't the decomposition that
makes sense for a particular front-end processor.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 15:48:46 EDT
From:      warren@pluto.UUCP (Warren Burstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for Sys V

In article <443@pluto.UUCP> warren@pluto.UUCP (Warren Burstein) writes:
:
:I asked my boss to order TCP/IP from Wollongong for a 3B2 and he came
:back and told me they stopped selling it because too many people were
:ripping it off and they won't sell it until they come up with a way to
:keep it from being stolen.

I posted this yesterday and today I got a phone call from Wollongong.
It seems that ATT has the exclusive to sell this product, and I got
a contact to find out what the problem is with the ATT side.

Sorry for the misinformation.
-- 
/|/~\~~\    The entire world             Warren Burstein
 |__/__/_/  is a very strange carrot.
 |          But the farmer               philabs!tg!pluto!warren
/           is not afraid at all.        Why doesn't life come with subtitles?

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 16:52:46 EDT
From:      kdw1@sphinx.uchicago.edu (Keith Waclena)
To:        comp.protocols.tcp-ip
Subject:   E-mail address for Wollongong Group wanted

We just installed Enhanced TCP/IP WIN/3B from the Wollongong Group on our
AT&T 3B15 running System V r2.1.  I am new at administering TCP/IP and am
having some trouble with the library routines.  Ftp, rlogin and the like are
working just fine.

Does anyone have an E-mail address for someone at the Wollongong Group that
can give me some advice?  Do they maintain some sort of mailing list or
whatever?  Please respond by mail as I don't normally read this newsgroup.

Just in case anyone else out there can help, here's a brief description of
my problems.

I let Wollongong's install script do the work of installation.  It gives me
a /usr/netinclude directory for things like socket.h.  Why are they not in
/usr/include?  Is there any reason why I shouldn't just cp them in there?
I have to conditionalize source code in order for the .h's to be found.  The
man pages for the socket compatibility library refer to the .h's as if they 
live in /usr/include.

I also find /usr/lib/libnet.a.  Am I supposed to use this via -lnet?  I get
similar (non)results whether I do or don't.

Typical problems have shown up in two short programs I tried to compile as
tests.  One is Rob Jacobs wm (window manager) which has compiled and run just
fine on about four machines that *I've* tried it on.  But when I try it on the
3B15, I get the following error from select(): 

	Bad address.	(aka EFAULT)

The exact lines of code are:

	int readmask;

	readmask = 01;

	while (select(8*sizeof(readmask), &readmask, 0, 0, 0) <= 0)
		perror("select");

What's wrong with this?  It loops forever with ``Bad address''.

In another program that compiles just fine, the loader barfs and complains
that it can't find socketpair(), which is in my set of man pages.  This happens
with or without -lnet.

Any help is much appreciated.  My apologies if this is the wrong newsgroup.

						Keith

--
Keith Waclena             University of Chicago Graduate Library School
                          1100 E. 57th Street, Chicago, Illinois   60637

                          ...ihnp4!gargoyle!sphinx!kdw1
#include <disclaimer.h>   kdw1@sphinx.UChicago.{EDU,BITNET,MAILNET,CSNET}

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 17:37:00 EDT
From:      mcc@nrc-ut.UUCP (Mecham Computer Associates)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Wanted: Honeywell 6000 TCP/IP

I am interested in obtaining any information whatsoever about
existing implementations of TCP/IP on the Honeywell 6000.  Please
respond by mail as I have less-than-regular access to USENET news.

Thanks in advance for your help,

=====================================================================
           Bob McKenzie  --  Mecham Computer Consultants

                          ihnp4!nrcvax!nrc-ut!mecham!bob  --  USENET
utah-cs!utah-gr!uplherc!nrc-ut!mecham!bob@SEISMO.CSS.GOV  --  ARPANET
=====================================================================

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 22:22:00 EDT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP


>Would someone please post a summary of reasons why use of Streams is
>an advantage.  Is this just another sales-hype buzzword?  or is there
>a reason Streams is better?  than sockets?  than psudo-sockets? or
>select?  Does the end user see any advantage?  faster response?  less
>CPU waste?  what?  Does anyone have some before & after figures on
>drivers that were converted to Streams?  Please share them with us.

Lets not compare apples and oranges here.

STREAMs is an architectural feature of the System V Rel 3 UNIX kernel.
STREAMs are to the kernel what pipes are to users, allowing various
kernel components to connected in useful configurations.  This is the
base used for kernel resident communications support in Sys V Rel 3.
Sockets in the Berkeley UNIX world can mean a couple of things, the
socket systems calls or the architecture of the kernel resident protocol
implementations.  In my opinion, the STREAMs mechanism is a much
cleaner way to implement things like communications protocols in the
kernel (but there are some limitations).  The user interface to streams
can be nearly anything you could want, but normally is via the
Transport Level Interface (TLI) which is a stream module which is intended
to present a standard transport service interface to users.  Most of
the TCP/IP implementations that I have seen for STREAMs provide the
socket interface, either via new systems calls or via an interface
emulation library.  As far as performance, I would suspect that a
STREAMs implementation would be at least as fast as functionally
equivalent code in the Berkeley kernel.

					Art Berggreen
					art@acc.arpa


------

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Jul-87 22:56:05 EDT
From:      wrk@abvax.icd.ab.com (William R. King)
To:        comp.protocols.tcp-ip
Subject:   telnet CR processing, bridge comm servers and TWG telnet

Last week I posted a query about CR processing. I was able to telnet
to TWG telnet from a 4.3 BSD system only if I was connected on a 
direct line. I was not able to connect when I was logged into the BSD
system via a Bridge CS/1. 

The problem stemed from the connection between the Bridge CS/1 and
the BSD 4.3 telnetd. The CS/1 was incorrectly sending \r\n as the
line terminator instead of the correct \r\0 sequence. The BSD telnetd
converted the \r\n sequence into \n and sent that into the pty. The
\n was passed on to TWG telnet which interpeted \n as "delete the 
word to the left of the cursor". So much for logging in.

I have since obtained a new release of Bridge CS/1 software (version
13000) which fixes the problem. They now offer the option (per port)
of sending \r\n or \r\0 as the line terminator. 

I thank the many people who took time to respond. It made life
much simpler.

Bill King
Allen-Bradley Company, Inc.
...!{decvax,pyramid}!abic!wrk

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 05:59:27 EDT
From:      piet@cwi.nl (Piet Beertema)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)


	>The latest RFC's can be gotten from LISTSERV@TCSVM.BITNET
I sure hope that this LISTSERV is more intelligent than
other LISTSERV's on BITNET: those aren't at all interested
in [the From: lines in] mail headers, only in the envelope
information. Unfortunately, when mails pass through gateways
to BITNET, the "user" in the envelope tends to be a pseudo
user (e.g. MAILER@FOO).

-- 
	Piet Beertema, CWI, Amsterdam
	(piet@cwi.nl)

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 10:09:07 EDT
From:      peter@xios.XIOS.UUCP (Peter Manson)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

In article <725@hjuxa.UUCP> kp@hjuxa.UUCP (Karen Paszamant) writes:
>
>what vendors have a System V Release 3.0 streams based tcp/ip product?
>

At a special session on STREAMS TCP/IP at the March TCP/IP Interoperability
Conference, the following vendors were on the panel (so they're at least
working on it):

Convergent Technologies / Lachmann Associates
Excelan
The Wollongong Group
Counterpoint
Interactive Systems

Sorry, I don't have addresses, etc. for them.

-- Hope this helps.

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 11:50:54 EDT
From:      Vince.Fuller@C.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   CMU-TEK Announcement

For some reason, this doesn't seem to have made it out. Apologies to any sites
that may receive duplicates. Also, to answer a couple of common questions:

    "I already have a license and distribution. Do I need another?"

If you already have a CMU license on file, you don't need another. You do need
to send us another tape if you want a more recent version.

    "The Tektronix license I have says I can't run it on some CPUs (i.e. the
    Microvax-I or II)"

This restriction no longer applies.

    "The version of the software that I have doesn't have <x> as advertised"

You probably have an old version of the software. The base version of the
software (the ACP version) that we are currently distributing is 6.2. Older
versions will not have all of the advertised features. As stated above, if you
want the latest release, send us another tape. At some point, we hope to setup
some system for sending updates over the network (but don't hold your breath).

    "Is the software still restricted to educational institutions only?"

In general, no. Our license does restrict use of the software explicitly to the
organization obtaining it from us (i.e. no redistribution or selling of it).

    "Is the software still restricted to use within the United States?"

Most of this restriction has been lifted, meaning that most countries not on
any technology export-control list may receive this software. If you don't know
if you are allowed to receive the software, send a letter to the distribution
address listed below - they will find out for you if there are problems.

		Vince Fuller, Dale Moore
		CMU-CSD Facilities

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

Date: 28 Jul 1987 11:11:08 EST
From: Dale.Moore@PS1.CS.CMU.EDU
Subject: CMU-TEK Announcement

A few simple questions....

	Are you looking for a well integrated IP/TCP on VMS?

	Are you tired of paying your annual salary per machine for
	networking software you use one hour a day?  

	Are you despondent over not having the sources to make the simple
	changes necessary to fix relatively minor problems?

If you answered yes to all the above, then have we got something for you.
It's not swamp land in Florida, nor is it prime gold fields in Alaska.
It's CMU-TEK IP/TCP for VMS.

For only $0 (thats Z-E-R-O dollars) you get

    - Common network utilities such as Telnet, FTP and Finger.
    - Domain network name resolver.
    - A mail generation and sending program.
    - Network servers for Telnet, FTP, SMTP and Finger.
    - An ACP process and device driver that implements IP, ICMP, TCP
      and as an extra special bonus UDP.
    - Subnets and packet reassembly.
    - Sources to utilities. Sources to documentation.  Sources to
      everything above that we can write on a tape.

What you don't get

    - Large monthly installment payment plan
    - Heavy Liscensing restrictions.  This is available to anyone,
      profit or nonprofit on any VAX processor.  Soon we will be able
      to send this to all 'reasonable' countries.
    - A big corporation with a three character name abbreviation.
    - 24 Hour telephone hotline support.  As a matter of fact, you get
      very little support.
    - User training seminars.  You'll have to find some other reason to
      get a free Road-Trip out of your employer.
    - Warranties.  No warranties expressed or implied.
    - VMS, BLISS or SCRIBE.  To recompile the sources and documentation,
      these necessary tools are not provided.

All of this, and VMSINSTAL compatible.

Some of you maybe skeptical.  Perhaps you think that this is only a minor
change over what is available from Tektronix.  Things do change, and now
they've changed for the better.

Some of you have refered to this as the CMU `enhanced' Tektronix code.
When you put flowers in the flower box outside your window, you enhance
the building.  When rip out and replace the plumbing, heating, electric
and replaster and repaint all the walls, and put on new siding, insulation
and roofing you've rebuilt.

It is no longer necessary to obtain a liscense from Tektronix to run the
CMU software.

To get a copy, send a US Postal Snail Mail letter to

	CMU-TEK IP/TCP Software Request
	Computation Center
	Carnegie Mellon University
	4910 Forbes Av.
	Pittsburgh, PA 15213

No warranties expressed or implied.  Postage and Handling may be extra.
Lifetime of offer limited.  All rights reserved.  Hey, I mean it!  We
don't mind giving the stuff away, but we don't want it stolen!

-------

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 12:32:20 EDT
From:      adelman@LBL-CSA1.ARPA (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP for any UNIX on any kind of AT

> Folks I need some help.  Is there anyone out there that has mil stnd
> simple mail runing on any version of an AT under any version of UNIX?

    The C version of the Software Tools Mail System runs under VMS as
well as System III, V, and BSD Unix and many derivatives including
Xenix.

    The current distribution runs on PC/ATs with Xenix and either
Excelan or NRC/Fusion TCP/IP and should be readily adaptable to other
variants of TCP.

					    Kenneth Adelman
					    LBL

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 13:32:42 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Wanted: Network Independent File Transfer Protocol (NIFTP)

Robert,

So far as I know, Blue-Book NIFTP was implemented for TOPS-20 and LSI-11
Fuzzballs quite a while ago (circa 1980). When I did the Fuzzball one I
started from a C-language program written at University College London.
Since the guys that wrote that program have since left UCL, I suggest
you contact Prof. Peter Kirstein, whose latest address can be found via
WHOIS. With his approval, I can forward the source code, which I still have
somewhere on an oxide plow.

Dave

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 13:48:38 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Why are these hosts trying to connect?

Steve,

Your observations are consistent with the scenario that you try to initiate
a TCP connection, give up after too short a time, then receive a SYN/ACK
from your destination, who might not have given up yet. The clue is the port
number, which is outside the range assigned most defined services.

Dave

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 13:53:20 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP in business

Folks,

As far as I know, the INTELPOST electronic mail system was the first to
adopt TCP/IP circa 1982. This is a facsimile-mail system first built by
BBN and then rebuilt by COMSAT Laboratories. It was operated by the US
Post Office and overseas affiliates. It use PDP11/40s and the fuzzball
network code. I know not if it is still in business.

Dave

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 14:12:31 EDT
From:      jqj@gvax.cs.cornell.edu (J Q Johnson)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Multiple netmasks

In article <12107@hi.UUCP> kurt@hi.UUCP (Kurt Zeilenga) proposes that
subnet routing be modified.  His proposal, slightly cleaned up, is
that:  When sending or forwarding to an IP address on a "local" subnetted
network (i.e. one for which the system has a directly connected interface),
the subnet mask should NOT be used directly to determine routing.  Instead,
it should be used to mask off a field of the destination IP address, then
that field should be used in a table lookup to determine the netmask to
use in examining the routing tables.

Thus, if net 128.84.0.0 is subnetted into 1 subnet with 16K hosts, 8
subnets with 4K hosts each, plus 1023 subnets with 255 hosts each,
the administrators of 128.84.0.0 could legislate that addresses
with the 2 highest bits of the third octet set to 0 would be
interpreted as 16 bits of net, 8 bits of subnet, and 8 bits of host,
while having both of those bits set would be interpreted as 2 bits of
subnet and 14 bits of host, and the rest would be interpreted as 4 bits
of subnet and 12 bits of host.  The table he proposes might have:

# subnet index mask is 0x0000c000
# network	index value	subnet mask
128.84.0.0	0x0000c000	0xffffc000
128.84.0.0	0x00008000	0xfffff000
128.84.0.0	0x00004000	0xfffff000
128.84.0.0	0x00000000	0xffffff00

It seems to me that this scheme would work, although at this point it
is unlikely ever to be adopted by the community as a standard.  The major
problems with it are (1) it is quite complex to administer [I spent 15
minutes constructing the above example, and am not confident I got it
right], and (2) it requires that every host that does routing know how
the network is broken into subnets (such hosts currently need to know
this information, but it consists of only a single number, the subnetmask).

Problem (2) is the serious one:  almost all host implementations would have
to be changed.  Given the problems we've had in getting vendors to support
the current subnetting scheme, it seems very unlikely that they would change
to support such a new scheme.

This raises the question of whether there is any less radical way to support
variable sized subnets, perhaps a solution that involves changing the code
only in gateways.  Anyone have any ideas?

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 14:30:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM TCP.


    Date: Fri, 24 Jul 87 23:32:20 EDT
    From: "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>

    I've heard nothing about aberrant behavior on Ether, so apparently they're
    only punishing their own pioneering customers at the moment....

Maybe they're just trying to go one up on DEC?  Remember that DEC
violates the spirit of the Ethernet hardware address by forcing the
Ethernet address to be algorithmically determined by the DECnet address,
resulting in Ethernet addresses which do not indicate the vendor of
hardware interface, as well as not ensuring globally unique addresses.

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 15:01:52 EDT
From:      jsol@EDDIE.MIT.EDU (Jon Solomon)
To:        comp.protocols.tcp-ip
Subject:   How do you break up a B class number?

I can think of a situation where different sized subnets would be useful.
At BU we have some networks (1 -3 ) which have alot of hosts on them
(> 10), one of our networks is growing rapidly (our backbone) and we 
have other networks which will be in the future growth of our class B network.
We also have networks with less than 10 hosts, some haveo only 1 (one) 
host and need a network because of technical limitations, such as Macintoshes
which need to talk to an appletalk gateway, or a Sun Server with only 2
clients and little or no growth predicted. In the latter case, using
a common subnetting scheme will be alright in the near future because
we have a total of 254 subnets. But what happens when we run out?
I know, I know, maybe by then we will be switching to ISO protocols
or someone will come up with a subnetting scheme that works better than
the one we have. See? I can answer my own questions :-).

Anyway, there is a need and it should be recognized.

--jsol

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 15:19:10 EDT
From:      paul@whuts.UUCP (HO)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes:

> Would someone please post a summary of reasons why use of Streams is
> an advantage.  Is this just another sales-hype buzzword?  or is there
> a reason Streams is better?  than sockets?  than psudo-sockets? or
> select?  Does the end user see any advantage?  faster response?  less
> CPU waste?  what?  Does anyone have some before & after figures on
> drivers that were converted to Streams?  Please share them with us.

Chapter 10 of the Bach book (The Design of the UNIX Operating System) has
a pretty good discussion and description on STREAMS. Also, Bach and 
others have also written some papers on the SVR3 STREAMS implementation, 
which differs slightly from the Research STREAMS.

	Paul Ho

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1987 18:42:16 PDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        hi!kurt@HC.DSPO.GOV (Kurt Zeilenga)
Cc:        braden@VENERA.ISI.EDU, tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re:  How do you break up a B class number?
This subnetting stuff can lead to bizzare situations that may sound
ok, but give some of the "semi-invisible glue" parts (like gateways,
routers, bridges) horrendous headaches.  Example:  you want a lot
of subnets, but you also want One Big One because you have a ton
of hosts on "one cable".  There is nothing that says you
cannot have more than one entwork number on the same "cable"!  So break
the 16 bits up into 256 nets of 256 hosts and assign 4 of the to the
main cable.   It's legal , but wil it work!?

Dan
-------
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 16:06:33 EDT
From:      hyc@UMIX.CC.UMICH.EDU (Howard Chu)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP w/SMTP for MSDOS, Minix, etc.

Here's the latest status report on Phil Karn's TCP/IP package,
stolen from the Usenet newsgroup comp.os.minix. (If you read
the News, you know...  }-)
	-- Howard Chu
	University of Michigan Computing Center, Unix Project

-=-=-=-=-=-=-=-=-=-

In article <389@louie.udel.EDU> galvin@UDEL.EDU (James M Galvin) writes:
>From: Paul Congdon <ptc@hpindda.hp.com>
>> Why doesn't someone just post the source....  It can't be all that big.

			No No No No No!

The package *IS* big, though much, much smaller than the PC/IP source
distribution.  Much easier for those who care to get it from louie, via
uucp, or from my bbs.  Why make the whole world pay distribution charges
for something so few have an immediate need for?

The code on louie was just updated by Phil to rev 870526.5, which contains
quite a few internal changes from the .0 release.  I'm working on integrating
his changes with stuff from a *lot* of other folks to issue another major
release.  I'd really hate to waste net bandwidth with code that's about to
be obsolete, since I assume most folks have 870526.0...

If we ever get a release that we're happy with, maybe a post to one of the
sources groups would be appropriate.  With the rate things are changing right
now, I don't think so.

The big news for this group is that the new release in a week or two will
have support for running as a single process under bsd or sysV.  Assume that
with a serial port driver for Minix (I don't have one?  Did the post not
get here?), that it will be trivial to bring it up there too as a single
process.  Not wonderful, but a start!

>The compressed tar file on our machine is 1/2 meg.  The uncompressed tar
>file is almost 1 meg.  That is a LOT of stuff to be mailing around.  Do
>we really want that?

Thanks for asking and not posting!
-- 

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

-=-=-=-=-=-=-=-=-=-=-=-
[Here are some older messages describing other means of getting the
sources. As far as I know, the most up to date version will always be
on Bdale's BBS, with louie getting updated soon after.  -- Howard]
-=-=-=-=-=-=-=-=-=-=-=-

In article <1049@bucsb.bu.edu.UUCP>, madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost) writes:
> I have a copy of Phil Karn's TCP/IP for the PC, which has a README
> file saying that you can do anything you want with it so long as its
> noncommercial.  I can shar it and send it to any interested parties.
> Note:  It's *quite* large.

This is now available from minix-server@bugs.nosc.mil under the pseudo
Message-Ids karn0@bugs.nosc.mil thru karn7@bugs.nosc.mil .

Also the 1.2 diffs and sources are here on bugs.
The compatibility list has not much new in it.

To review:
-----------------------------------------------------------------------------
Subject: archive service on bugs.nosc.mil
Keywords: automatic mail archive server
Message-ID: <690@cod.UUCP>
Date: 20 May 87 19:22:17 GMT

An archive retrieval service for old comp.os.minix articles is set
up on bugs.nosc.mil using E-mail.  Everything available to anonymous
FTP in directory pub/Minix can be obtained by sending a mailed request
to minix-server@bugs.nosc.mil or nosc!minix-server .  Include in the
message, either among the header fields or the body, a line like:

Reply-To: <your mail address>

and following that a line or lines naming desired files e.g.:

send compatibility
send SUBJECTS
send 1180@botter.cs.vu.nl

to get an automatic mailed reply.
Your mail address should look something like one of these examples:

you@stolaf.uucp
cs.vu.nl!giant@seismo.css.gov
person%utoronto.bitnet@wiscvm.wisc.edu
user%ulowell.csnet@relay.cs.net
honcho%durham.mailnet@mit-multics.arpa    .

FTP should happen during off-hours only.
E-mail is not free, either; abuse of the system will cause bad karma.
Contents may have settled during shipment.


Vincent Broman,  code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA
Phone: +1 619 225 2365    Internet: broman@nosc.mil   Uucp: sdcsvax!nosc!broman

-=-=-=-=-=-=-=-=-=-=-

My mailbox overrunneth!!!  I'm averaging one request per hour for
Phil's code. Here's how to obtain the distribution via anonymous
UUCP from 'ncc'.

First, add the following line to your L.sys file:

ncc Any ACU 2400 14034250342 "" \r ogin:--ogin: nuucp

or for 1200 baud access

ncc Any ACU 1200 14034250342 "" BREAK\r ogin:-BREAK\r-ogin: nuucp

The distribution is split into four files as follows:

-rw-rw-r--   1 lyndon         0 Jul 22 11:24 FILES
-r--r--r--   1 lyndon     61089 Jul 21 11:53 exe.tar.Z
-r--r--r--   1 lyndon     42474 Jul 21 11:54 misc.tar.Z
-r--r--r--   1 lyndon    142666 Jul 21 11:52 src.tar.Z
-r--r--r--   1 lyndon     96487 Jul 21 11:54 tnc.tar.Z

exe.tar.Z contains the MS-DOS binaries
misc.tar.Z is the documentation and bm (Bdales Mailer)
src.tar.Z is the source code for everything except bm
tnc.tar.Z contains the Terminal Node Controller stuff (not needed for Minix)
FILES is a list of the current directory contents

All files are in 16 bit compressed format.

Once you've decided which files you require, queue up a SEPERATE
request for each file as follows:

	uucp ncc!~/pub/ka9q/src.tar.Z /usr/spool/uucppublic/ka9q/
			    ^^^^^^^^^
			Replace with appropriate filename

You should take a copy of the FILES file first, just incase the
distribution breakdown is changed.

Please note that this is NOT the most current release of the
software. I have been waiting for the new versions to stabalise
a bit before bringing an updated copy in. Given the amount of
interest I will be obtaining the most current release in the next
couple of days. You might want to wait for it (I will post an
announcement as soon as it's online).

If you have any problems with UUCP, send mail to me and I'll
check into it.

Lyndon Nerenberg  VE6BBM
alberta!ncc!lyndon  pyramid!ncc!lyndon

-- 
Ollie for president: the tradition continues.

-=-=-=-=-=-=-=-=-=-=-=-

> Here's how to obtain the distribution via anonymous
> UUCP from 'ncc'.

For those of you with anonymous ftp access, it is also available from
louie.udel.edu, "10.0.0.96", in the "pub" directory, file name
"ka9q_all.tar.Z".

Jim

-=-=-=-=-=-=-=-=-=-=-=-
Bdale's BBS can be reached at (303) 593-0766, up to 2400bps, almost
24 hours a day. He claims the access restrictions for first time
users are long enough to allow downloading the entire package at
1200 baud.
	-- Howard

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1987 19:27:09 PDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        phri!bc-cis!pluto!warren@NYU.ARPA (Warren Burstein)
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re: Wollongong TCP/IP for Sys V
Bashing Wollongong is probably more fun now that they are on the Internet now
and we know they see these flames.  But, Burstein's message really
puzzles me.  If Wollongong's stuff is so bad, why is everyone stealing it?

Dan
-------
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1987 20:05:16 PDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        gorodish!guy@SUN.COM (Guy Harris)
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re: Streams TCP/IP
Guy Harris said something that made me see red:  the TLI uses state 
information that is kept in userland.  Does that mean that it takes
parameters from userland and then operates on them in kernelland
or doe sit mean that it uses userland dataspace to keep some state
variables that the user can change between system calls to get data
to or form the stream?  If so, it is a potential source of random
havoc or invidious hackery to accomplish amazing ends.  In short, I
am asking:  is this a security or integrity breach ot not?

Dan
-------
-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 17:54:27 EDT
From:      ELINSKY@YKTVMX.BITNET (Jay Elinsky)
To:        comp.protocols.tcp-ip
Subject:   Source routing


This is from Jay Elinsky at IBM Yorktown, originally sent on the Bitnet-
based IBM TCP/IP For VM Mailing list.  He asked that it be forwarded to
the TCP/IP mailing list.    - Mark Bodenstein, Cornell University

----------------------------Original message----------------------------
I'm one of the developers of the VM code at Yorktown, and I want to
clarify some possible misconceptions on this subject:

1) We use source routing only on Token Ring.  Even on Token Ring, we can
certainly also route through a router, if the destination host is on
a different net or subnet.  If the destination host is on a different
ring with the same net or subnet number, we do indeed use source routing.
I believe that this is consistent with the architecture of the Token
Ring.  Is it inconsistent with any existing implementation of TCP/IP
over Token Ring?  If so, I'd certainly like to know about it.

2) Re "No RIF field, no function":  If a host is on the same ring, the
ARP code will recognize it, and subsequent packets between the hosts have
no routing field at all.

3) Our TCP/IP certainly is inter-operable with other TCP/IP implement-
ations.  That is our reason for supporting TCP/IP. To repeat what I
said in (1), the source routing issue is only on Token Ring, and to
the best of my knowledge our implementation is consistent with other
TCP/IP Token Ring implementations, and with Token Ring architecture.

4) In the VM code, the Token Ring routing information is kept as part
of the address translation cache.  I think that's logical.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 29 Jul 1987 17:54:27 EDT
From:      Jay Elinsky <ELINSKY%YKTVMX.BITNET@wiscvm.wisc.edu>
To:        Mark Bodenstein <MAB@CORNELLC>, Michael Hojnowski <MQH@CORNELLC>
Subject:   Source routing

This is from Jay Elinsky at IBM Yorktown, originally sent on the Bitnet-
based IBM TCP/IP For VM Mailing list.  He asked that it be forwarded to
the TCP/IP mailing list.    - Mark Bodenstein, Cornell University

----------------------------Original message----------------------------
I'm one of the developers of the VM code at Yorktown, and I want to
clarify some possible misconceptions on this subject:

1) We use source routing only on Token Ring.  Even on Token Ring, we can
certainly also route through a router, if the destination host is on
a different net or subnet.  If the destination host is on a different
ring with the same net or subnet number, we do indeed use source routing.
I believe that this is consistent with the architecture of the Token
Ring.  Is it inconsistent with any existing implementation of TCP/IP
over Token Ring?  If so, I'd certainly like to know about it.

2) Re "No RIF field, no function":  If a host is on the same ring, the
ARP code will recognize it, and subsequent packets between the hosts have
no routing field at all.

3) Our TCP/IP certainly is inter-operable with other TCP/IP implement-
ations.  That is our reason for supporting TCP/IP. To repeat what I
said in (1), the source routing issue is only on Token Ring, and to
the best of my knowledge our implementation is consistent with other
TCP/IP Token Ring implementations, and with Token Ring architecture.

4) In the VM code, the Token Ring routing information is kept as part
of the address translation cache.  I think that's logical.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 21:42:16 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re:  How do you break up a B class number?

This subnetting stuff can lead to bizzare situations that may sound
ok, but give some of the "semi-invisible glue" parts (like gateways,
routers, bridges) horrendous headaches.  Example:  you want a lot
of subnets, but you also want One Big One because you have a ton
of hosts on "one cable".  There is nothing that says you
cannot have more than one entwork number on the same "cable"!  So break
the 16 bits up into 256 nets of 256 hosts and assign 4 of the to the
main cable.   It's legal , but wil it work!?

Dan
-------

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 22:27:09 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for Sys V

Bashing Wollongong is probably more fun now that they are on the Internet now
and we know they see these flames.  But, Burstein's message really
puzzles me.  If Wollongong's stuff is so bad, why is everyone stealing it?

Dan
-------

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Jul-87 23:05:16 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

Guy Harris said something that made me see red:  the TLI uses state 
information that is kept in userland.  Does that mean that it takes
parameters from userland and then operates on them in kernelland
or doe sit mean that it uses userland dataspace to keep some state
variables that the user can change between system calls to get data
to or form the stream?  If so, it is a potential source of random
havoc or invidious hackery to accomplish amazing ends.  In short, I
am asking:  is this a security or integrity breach ot not?

Dan
-------

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Jul-87 01:35:21 EDT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Help: TCP/IP for business application


We are currently installing an ACC TCP/IP interface on the (purely)
Administrative IBM3090 here at BU, they have also installed a Sun
system.  The CLA Dean's office is currently using a SUN3/180 and
several diskless clients (that's TCP packets like all getout) and are
moving their databases (which have been Unix based for many years) to
that system. Several other departments are doing compatible things
like that.

The goal is to distribute the management of registration, grant and
other information campus-wide via TCP/IP in the near future.  I doubt
they would at this time even consider anything other than TCP for
their applications which (using typically the Ingres and Adabas(e?)
data base systems) relies upon the heterogenous network to make
accessible IBM/MVS, IBM/VM, Suns, Vax/VMS and other systems
(Macintoshes via Kinetics boxes if I can ever finish reading my mail.)

Boston University is generally considered to be within the United
States of America and although you might write us off as academia you
might want to consider the business involved in running a private
university of over 25,000 students. We're probably a bigger business
than you are (probably approaching Fortune 500, I dunno, never thought
of it that way.) So there.

	-Barry Shein, Boston University

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Jul-87 06:24:00 EDT
From:      meth@ztivax.UUCP
To:        comp.protocols.tcp-ip
Subject:   ISO - TCP/IP gateway? - (nf)

Here in Munich,W.-Germany, we have installed an Ethernet with a lot of
different systems on it, speaking TCP/IP.
Now two more systems could be connected to the net, but these only speak
ISO (not yet in the market).

Is there any hardware or software which could work as a gateway between
these two protocol families?

Any advice would be regret!

	Wilhelm Methfessel
	Siemens AG
	Munich
	W.-Germany
	seismo!unido!ztivax!meth

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jul 87  9:52:41 MDT
From:      Robert Butler <rbutler@yuma.arpa>
To:        "CALVIN R. GEORGE" <george@eglin-vax.arpa>
Cc:        tcp-ip@sri-nic.arpa, rbutler@yuma.arpa
Subject:   Re: SEVERAL copies of message received
I have received many copies also (8). Some of them have a different closing
address in the signature block.

I also receive dual and triple copies of other msgs addressed to tcp-ip
and there is no specific delimiter to single them out as to why.

We are a MIL site running a BBN C70,(BBN OS V) behind an LSI/11-23 gateway
attached to Milnet Node 75. The gateway makes our system a subnet 6.1.0.1
under the 26.3.0.75 DDN address.

This has been sparodically going on for several months. I have read all the
net-problems reported on the tcp-ip news group and thought the problem had 
been defined and (will be?) corrected.

Regards
       Bob
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Jul-87 11:16:07 EDT
From:      louie@TRANTOR.UMD.EDU (Louis A. Mamakos)
To:        comp.protocols.tcp-ip
Subject:   Re: Why are these hosts trying to connect?

You might also want to log both port numbers;  it may be possible that you
are seeing broken FTP data connections.

louie

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Jul-87 11:52:41 EDT
From:      rbutler@YUMA.ARPA (Robert Butler)
To:        comp.protocols.tcp-ip
Subject:   Re: SEVERAL copies of message received

I have received many copies also (8). Some of them have a different closing
address in the signature block.

I also receive dual and triple copies of other msgs addressed to tcp-ip
and there is no specific delimiter to single them out as to why.

We are a MIL site running a BBN C70,(BBN OS V) behind an LSI/11-23 gateway
attached to Milnet Node 75. The gateway makes our system a subnet 6.1.0.1
under the 26.3.0.75 DDN address.

This has been sparodically going on for several months. I have read all the
net-problems reported on the tcp-ip news group and thought the problem had 
been defined and (will be?) corrected.

Regards
       Bob

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Jul-87 14:19:00 EDT
From:      CDC-DDN@DDN3.ARPA
To:        comp.protocols.tcp-ip
Subject:   SMTP host number notation


  
SMTP RFC-821 defines a 'host number' that supplements the regular domain
name and internet address notation.  For example, PERSON @ #354.  (refer
to page 30 in the syntax for <element>, and to page 31 in the last
paragraph.)
  
Does anyone know what this #host number is and where it comes from?  Is
this a feature that is normally expected to be implemented in SMTP, or is
it a left-over from years past (NCP?).  Any pointers will be appreciated.
  

Mike Sanders

CDC-DDN @ DDN3.ARPA

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 87 14:19 EDT
From:      CDC-DDN @ DDN3.arpa
To:        tcp-ip @ sri-nic.arpa
Cc:        CDC-DDN @ DDN3.arpa
Subject:   SMTP host number notation

  
SMTP RFC-821 defines a 'host number' that supplements the regular domain
name and internet address notation.  For example, PERSON @ #354.  (refer
to page 30 in the syntax for <element>, and to page 31 in the last
paragraph.)
  
Does anyone know what this #host number is and where it comes from?  Is
this a feature that is normally expected to be implemented in SMTP, or is
it a left-over from years past (NCP?).  Any pointers will be appreciated.
  

Mike Sanders

CDC-DDN @ DDN3.ARPA

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Thu 30 Jul 87 18:07:20-PDT
From:      Karl Auerbach <AUERBACH@CSL.SRI.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   STREAM, TLI, and (of all things) MAP 3.0
I was wondering whether TLI (Transport Level Interface) is an intrinsic
part of STREAMS?  If severable, is TLI required by AT&T?

Can TLI support fully asynchronous operations.  In other words can
I initiate a bunch of connects, sends, listens, receives.., continue
running and get some sort of call-back, up-call, AST (pick your favorite
name) when something completes?

If TLI is an ISO transport interface, who provides graceful close?  (ISO
transport does not have graceful close, that's part of session.)

I have on my desk a copy of a working document from the GM MAP 3.x folks.
It defines a programmatic interface for applications.  If anyone is familiar
with that and TLI, I'd like to hear your comments.

			--karl--
-------
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Jul-87 16:01:22 EDT
From:      leong+@ANDREW.CMU.EDU (John Leong)
To:        comp.protocols.tcp-ip
Subject:   CMU-TEK IP code for VMS : qualification



Further to a recent posting concerning the CMU-TEK IP software for VMS, I
have the following qualifications :

[1]  The software is not really free. In the past, when we were receiving
requests at a rate of 5 or so a month, programmers will just bang out the
tape and levy a charge of something like $25 just to cover postage. In view
of the recent increase requests for the software, we are having
administration and operation to handle the mechanic of request processing. We
will be levying a charge of $100 per request to cover media, postage,
handling, and. hopefully, keep out potential nusiance requests.

[2]  While the software has been substantially re-written and significantly
improved by the staff of our CS department, I would like to fully acknowledge
the contribution by Tektronix. Not only have they the foresight and
committement to carry out the original development, they have also done the
academic and research community a great big favour by letting CMU distribute
the software at virtually no cost - even if it is not supported. I can name a
few university developments that got complete tangled up by licensing by
corporations that has only money in their brain.

[3] Finally, the software is ** NOT SUPPORTED and has absolutely NO
WARRANTIES **.  Unsupported software may be fine for organisations that have
significant local expertise or want to take advantage of the available source
(in Bliss) to make local enhancements. It should not be used simply on
account of its low cost. This can be dangerously  deceptive since you can end
up paying bundles more if the package starts causing all sorts of instablity
with your system and you have no idea what it is doing [and no one to get
help from!] . For quite a number of organisations, you may well be advised to
get fully supported and warrantied software from commercial vendors instead.


John Leong

CMU

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 1987 23:07:06 PDT
From:      Douglas M. Olson <dolson@ADA20.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   data representation in FTP
Tedious but trivial for people who use these documents, I hope:

I'm reading a draft test plan in order to spot whoppers and fix it up.
In some areas I'm not extremely qualified...oh well.  Problem: the
draft for testing FTP calls for transmission of data in "text, ASCII,
EBCDIC, and binary" to and from the test host, which will be a VAX/VMS
system.  Seems inspecific to me...  I'm referencing what looks like
MIL-STD 1780 page 9 (which is on page I-341 of the white books which
I DON'T really know how to use).  

"5.2.1 ASCII format: ...is intended primarily for transfer of text
files, except when both hosts would find the EBCDIC type more
convenient.  The sender converts the data from his internal format to
the standard 8-bit NVT ASCII representation..."

I'm still in trouble, but now I know its because I don't know FTP well
enough.  Question 1) When would a VAX/VMS FTP decide that EBCDIC is
convenient? That is, is this likely/mandatory to be a user-selectable
option in a reasonable FTP implementation on VMS?  Seems like the
default in this case is that if a VAX/VMS user gets a file from a
machine which uses EBCDIC, it is the remote (EBCDIC) host's job to
translate it before transmission, unless the user wants EBCDIC.

If the VMS FTP user CANNOT specify EBCDIC, then I have to tell the
test plan writers to fix this... comments from you folks anxiously
solicited!

Doug (dolson @ Ada20)

-------
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Jul-87 21:07:20 EDT
From:      AUERBACH@CSL.SRI.COM (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   STREAM, TLI, and (of all things) MAP 3.0

I was wondering whether TLI (Transport Level Interface) is an intrinsic
part of STREAMS?  If severable, is TLI required by AT&T?

Can TLI support fully asynchronous operations.  In other words can
I initiate a bunch of connects, sends, listens, receives.., continue
running and get some sort of call-back, up-call, AST (pick your favorite
name) when something completes?

If TLI is an ISO transport interface, who provides graceful close?  (ISO
transport does not have graceful close, that's part of session.)

I have on my desk a copy of a working document from the GM MAP 3.x folks.
It defines a programmatic interface for applications.  If anyone is familiar
with that and TLI, I'd like to hear your comments.

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

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 00:16:50 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  adversity or perversity

Chris,

You are asking for a lot. In conventional wisdom multi-network Ethernets
are considered somewhat unstable and, so far as I know, are unsupported
by current host and gateway vendors. Some experimentation has been done
in the NSFNET community with these things, but the gadgets with which this
has been done (fuzzballs) are probably best left in their original cages.

See RFC1009 for further discussion on this point.

Dave

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 01:25:33 EDT
From:      monkey@unixprt.UUCP (Monkey Face@unixprt)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

In article <24335@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
> I won't bother replying to the whiny little question at the end,...
Two n's in 'whinny', besides I was laughing at the time.
Several people at Sun have mailed me the answer anyway.  Anyone who
wants to know can ask me via mail.
> > ...A vendor that must rely on ATT
> > to provide a base, a strategy based on sockets does not seem appropriate
> > in the long term.
> That depends on several things.  First, it depends on whether the
> vendor wants to continue to depend on AT&T to provide a base, especially
> given the S5R3 licensing agreement.  Second, it depends on whether
> they want to re-port the rest of what they've done to S5R3.
Most current and near future UNIX vendors do and will use S5Rn based
ports.  I beleive that vendor management can see the costs associated
with not following this path.  Their customer will demand upward
compatible functionality.

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 02:07:06 EDT
From:      dolson@ADA20.ISI.EDU (Douglas M. Olson)
To:        comp.protocols.tcp-ip
Subject:   data representation in FTP

Tedious but trivial for people who use these documents, I hope:

I'm reading a draft test plan in order to spot whoppers and fix it up.
In some areas I'm not extremely qualified...oh well.  Problem: the
draft for testing FTP calls for transmission of data in "text, ASCII,
EBCDIC, and binary" to and from the test host, which will be a VAX/VMS
system.  Seems inspecific to me...  I'm referencing what looks like
MIL-STD 1780 page 9 (which is on page I-341 of the white books which
I DON'T really know how to use).  

"5.2.1 ASCII format: ...is intended primarily for transfer of text
files, except when both hosts would find the EBCDIC type more
convenient.  The sender converts the data from his internal format to
the standard 8-bit NVT ASCII representation..."

I'm still in trouble, but now I know its because I don't know FTP well
enough.  Question 1) When would a VAX/VMS FTP decide that EBCDIC is
convenient? That is, is this likely/mandatory to be a user-selectable
option in a reasonable FTP implementation on VMS?  Seems like the
default in this case is that if a VAX/VMS user gets a file from a
machine which uses EBCDIC, it is the remote (EBCDIC) host's job to
translate it before transmission, unless the user wants EBCDIC.

If the VMS FTP user CANNOT specify EBCDIC, then I have to tell the
test plan writers to fix this... comments from you folks anxiously
solicited!

Doug (dolson @ Ada20)

-------

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 08:57:01 EDT
From:      schoff@NIC.NYSER.NET (Marty Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for Sys V


Dan,

I personally haven't heard of anyone stealing it, (that message
really took me by surprise), but I'd propose that the reason why
people might "steal" tcp/ip it is that it is CURRENTLY the only
game in town.  AT&T donated thousands of 3b machines to the universities,
(RPI has almost 30 of them), stealing the networking software
puts it in the "matching" price range of the hardware itself.

What may happen as soon as the "public domain" implementations
are available is what has happened with VMS tcpip networking
in the past (and accelerating right now), either you don't
buy a TWG product at all or you buy one for "stability" sake
and run TEK/CMU/TCP everywhere else.

Marty

PS:  RPI told AT&T that we HAD to have tcp/ip and ethernet on
	ours or we simply wouldn't use them, AT&T delivered
	tcp/ip.  From my discussions with others who took
	donated equipment, stances like that were rare.

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 10:21:22 EDT
From:      mark@applix.UUCP (Mark Fox)
To:        comp.protocols.tcp-ip
Subject:   Re: STREAM, TLI, and (of all things) MAP 3.0

In article <8707310111.AA28460@ucbvax.Berkeley.EDU> AUERBACH@CSL.SRI.COM (Karl Auerbach) writes:
>... several questions follow...

I just put down the UNIX System V manuals from AT&T and Prentice-Hall.
I also have been looking at our Bell Technologies 386 running S5V3. Here
is what I have observed:

>I was wondering whether TLI (Transport Level Interface) is an intrinsic
>part of STREAMS?  If severable, is TLI required by AT&T?

TLI is implemented by a library called libnsl_s.a in /usr/lib. It contains
all of the t_ calls. TLI is implemented on top of STREAMS. Is it severable or
required? Check the licensing agreements...

>Can TLI support fully asynchronous operations.  In other words can
>I initiate a bunch of connects, sends, listens, receives.., continue
>running and get some sort of call-back, up-call, AST (pick your favorite
>name) when something completes?

Both synchronous multiplexing using the poll (== select) call and
asynchronous multiplexing with the I_SETSIG ioctl (== SIGIO) are supported
in addition to a non-blocking option (by setting O_NDELAY) on most of the calls

>If TLI is an ISO transport interface, who provides graceful close?  (ISO
>transport does not have graceful close, that's part of session.)

The UNIX System V Network Programmer's Guide says that graceful close
is an optional procedure. Does this mean that t_sndrel defaults to
a t_snddis for ISO?

>I have on my desk a copy of a working document from the GM MAP 3.x folks.
>It defines a programmatic interface for applications.  If anyone is familiar
>with that and TLI, I'd like to hear your comments.

MAP's programmatic interface, from my hazy recollection, is primarily at
the CASE and directory service interfaces in the application layer. TLI
is a transport layer interface.

Now I have a question based on an observation: 

It seems that AT&T's TLI primitives are not very different from the
Berkeley socket calls. For example: poll == select; t_open == socket;
t_bind, t_accept, t_connect, t_listen == bind, accept, connect, listen;
t_rcv, t_snd == recv/recvfrom, send/sendto; t_snddis == shutdown...

Did NIH have something to do with the design of TLI?

Actually the real question is:

If I have an application that communicates with other processes using
fairly vanilla socket calls, couldn't I just implement the socket calls
for the System V port using TLI calls or at least encapsulate the Unix
calls within my own primitives? Or am I missing some basic incompatibility?
By vanilla I mean that I am not particularly interested in exploiting
protocol options such as call user data or graceful close.

Oh yes, another question:

Are there any System V equivalents for the Berkeley Network library functions,
such as gethostent and inet_addr, and files such as /etc/hosts and
/etc/services? I found no mention in the Network Programmer's Guide or
Release Notes. Do I have to pay extra for them?
-- 
                                    Mark Fox
       Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300
                    uucp:  seismo!harvard!m2c!applix!mark

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 1987 12:58:41 EST
From:      Dale.Moore@PS1.CS.CMU.EDU
To:        info-vax@kl.ri.com,  tcp-ip@SRI-NIC.ARPA, tektcp%kla.weslyn%wesleyan.bitnet@VMA.CC.CMU.EDU
Subject:   CMU-TEK questions
Ever read Mad Magazine?  How about that section "Snappy Answers to Stupid
Questions"?  Well this is just like that, only the questions are about
CMU-TEK VMS IP/TCP software, and some of the questions aren't so stupid.

Q: How do I get the software?
A: Like my post said, send mail to

	CMU-TEK IP/TCP Software Request
	Computation Center
	Carnegie Mellon University
	4910 Forbes Av.
	Pittsburgh, PA 15213

They'll answer your questions and give you a copy of a license to sign.
Once we receive the signed license, we'll mail you the software.  The
license says that the software is owned by CMU-TEK and that CMU isn't
responsible for problems caused by this software etc.

It will take a couple of weeks to process this stuff.  Please,
no rush exceptions.

Q: We have an old license from Tektronix. Do we need to re-license?
A: CMU would like everyone to have the same type of license to this
software.  Our current license is probably the least restrictive
of any of the past.  You might want to contact the above address
and see what current license restrictions are.

Q: Please explain "Postage and Handling may be extra"?
A: We are currently charging $20 for the tape, postage, handling and
the cost of reproducing one hardcopy of the documentation.  This may
increase to $50 sometime in the future. We use to ask that the user
send us the tape and a prepaid mailer.  But that was a hassle because
some wouldn't send enough postage and others wouldn't send the tape.

Q: Sounds like you don't like Tektronix?
A: Tektronix did good by us.  Their pioneering work with this stuff
was a great help.  Some of their original framework and design flavor
remains.  In retrospect we might have been better starting from scratch.
We are very grateful to the technical and administrative folks at
Tektronix.

Q: Are you trying to put TWG and other VMS IP/TCP vendors out of business?
A: No.  They do hand-holding.  And some of them do it quite well. We
do not hand-hold.  Some of those vendors are offering innovative
and custom solutions to some of the IP/TCP problems.  Most are willing
to stand behind their work and see that it is working almost perfectly.
We might occasionally take the approach of "Since you found the bug,
you can help us find the fix".
-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      31 JUL 87 15:29-PDT
From:      DHWalker%UCIVMSA.BITNET@wiscvm.wisc.edu
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Telnet spooling for Unix
Received: from ORION by UCICP6 with PMDFs; 31 Jul 1987 15:04:01
Received: from localhost by orion.cf.uci.edu id a009621; 31 Jul 87 14:59 PDT
Date: Fri, 31 Jul 87 14:59:55 -0700
From: David Walker <dwalker@orion.cf.uci.edu>

Does anyone know of a filter program for Unix's spooling system which
can make a telnet request for its printer?  We would like to attach
(cheap) serial printers to terminal servers and have them accessible
from our Sequent system (among others).

                                             David Walker
                                             Network Services Manager
                                             UC Irvine
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 12:30:00 EDT
From:      sandrock@uxc.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: IBM TCP.


>/* Written  1:30 pm  Jul 29, 1987 by DCP@QUABBIN.SCRC.SYMBOLICS.COM in uxc.cso.uiuc.edu:comp.protocols.tcp-ip */
>
>    Date: Fri, 24 Jul 87 23:32:20 EDT
>    From: "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>
>
>    I've heard nothing about aberrant behavior on Ether, so apparently they're
>    only punishing their own pioneering customers at the moment....
>
> Maybe they're just trying to go one up on DEC?  Remember that DEC
> violates the spirit of the Ethernet hardware address by forcing the
> Ethernet address to be algorithmically determined by the DECnet address,
> resulting in Ethernet addresses which do not indicate the vendor of
> hardware interface, as well as not ensuring globally unique addresses.
>
   DECnet uses the node address to set the least significant 16 bits of the
   48-bit Ethernet hardware address while setting the most significant 32
   bits to a "known" constant value.  Specifically, the Ethernet address
   will be AA-00-04-00-xx-xx, where the xx-xx fields are the DECnet node
   address (area-number * 1024) + node-number.
     There may be both certain advantages and also disadvantages to this
   approach, but is it true that these addresses are not globally unique?

     Mark Sandrock, (sandrock@uxc.cso.uiuc.edu)

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 12:55:55 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Streams TCP/IP

Is streams in the SVID?  Really?  Well DAMN ship back this AT&T SVR3
release because streams ain't in it.

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 13:02:06 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for Sys V

The TWG code for the 3B2 comes from AT&T.  I wasn't aware you could
buy it at all from TWG (I wish I were wrong, I'd expect that the
product would be better direct).  Anyhow, TWG could avoid pirating
by using the same method as the SUN PCNFS code.  The software shuts
down if it notices datagrams from another of the same licensed code
on the net.

-Ron

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 13:44:35 EDT
From:      dougm@violet.isc.COM ("Doug McCallum")
To:        comp.protocols.tcp-ip
Subject:   Re: STREAM, TLI, and (of all things) MAP 3.0

In reply to your message of Thu 30 Jul 87 18:07:20-PDT
-------
 > I was wondering whether TLI (Transport Level Interface) is an intrinsic
 > part of STREAMS?  If severable, is TLI required by AT&T?

It is possible to have streams without TLI.  TLI is implemented as a STREAMS
module and library code.  TLI is the programmer interface to the Transport
Provider Interface which is the format of messages used to communicate with
a transport protocol module.  STREAMS by itself doesn't define message
format, just message type.

TLI is required to be implemented if the Network Extensions are supported.
It is possible to leave that out of the system.  You aren't required to use
TLI as a user, but if you don't have an alternate interface, its easier to
use TLI than to process all of the message formats yourself.

 > Can TLI support fully asynchronous operations.  In other words can
 > I initiate a bunch of connects, sends, listens, receives.., continue
 > running and get some sort of call-back, up-call, AST (pick your favorite
 > name) when something completes?

Yes.  When a t_bind is done, it includes a count of maximum pending connect
requests, similar to what listen does in the socket world.  The difference
being that with TLI, you can accept, connect or both on the stream.
Accepting a connection requires first listening for a connection request.
You can read in multiple connection requests and then decide which ones to
accept or reject.  Accepts can either be done on a new stream or on the same
stream you received the request on.

You can also elect to receive a signal when a stream has data at the stream
head.  To determine which stream has the data, the poll system call is used
in much the same way as select on a BSD system.  TLI (actually STREAMS) is
flexible enough that you can initiate several connections and not wait for
the results and then go back later to determine if they are done.
One thing to note, the poll call only works on STREAMS descriptors and not
on things like ttys.

 > If TLI is an ISO transport interface, who provides graceful close?  (ISO
 > transport does not have graceful close, that's part of session.)

TLI only provides a graceful close if the underlying transport provides it.
TLI is ISO in flavor, it is supposed to be general enough for other
protocols.  The calls are similar to the ISO service primitives.
Unfortunately, this has some problems for TCP, primarily in how to deal with
urgent data.  Urgent data is not the same thing as expedited data.

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 13:58:41 EDT
From:      Dale.Moore@PS1.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   CMU-TEK questions

Ever read Mad Magazine?  How about that section "Snappy Answers to Stupid
Questions"?  Well this is just like that, only the questions are about
CMU-TEK VMS IP/TCP software, and some of the questions aren't so stupid.

Q: How do I get the software?
A: Like my post said, send mail to

	CMU-TEK IP/TCP Software Request
	Computation Center
	Carnegie Mellon University
	4910 Forbes Av.
	Pittsburgh, PA 15213

They'll answer your questions and give you a copy of a license to sign.
Once we receive the signed license, we'll mail you the software.  The
license says that the software is owned by CMU-TEK and that CMU isn't
responsible for problems caused by this software etc.

It will take a couple of weeks to process this stuff.  Please,
no rush exceptions.

Q: We have an old license from Tektronix. Do we need to re-license?
A: CMU would like everyone to have the same type of license to this
software.  Our current license is probably the least restrictive
of any of the past.  You might want to contact the above address
and see what current license restrictions are.

Q: Please explain "Postage and Handling may be extra"?
A: We are currently charging $20 for the tape, postage, handling and
the cost of reproducing one hardcopy of the documentation.  This may
increase to $50 sometime in the future. We use to ask that the user
send us the tape and a prepaid mailer.  But that was a hassle because
some wouldn't send enough postage and others wouldn't send the tape.

Q: Sounds like you don't like Tektronix?
A: Tektronix did good by us.  Their pioneering work with this stuff
was a great help.  Some of their original framework and design flavor
remains.  In retrospect we might have been better starting from scratch.
We are very grateful to the technical and administrative folks at
Tektronix.

Q: Are you trying to put TWG and other VMS IP/TCP vendors out of business?
A: No.  They do hand-holding.  And some of them do it quite well. We
do not hand-hold.  Some of those vendors are offering innovative
and custom solutions to some of the IP/TCP problems.  Most are willing
to stand behind their work and see that it is working almost perfectly.
We might occasionally take the approach of "Since you found the bug,
you can help us find the fix".

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 87 14:30:06 EDT
From:      jqj@gvax.cs.cornell.edu (J Q Johnson)
To:        arpa.tcp-ip
Subject:   Re:  How do you break up a B class number?
Dan Lynch <LYNCH@A.ISI.EDU> suggests (in jest, I think) a solution to
the heterogenous subnet problem:
> . . . have more than one entwork number on the same "cable"!  So break
>the 16 bits up into 256 nets of 256 hosts and assign 4 of the to the
>main cable.   It's legal , but wil it work!?

No, it probably won't work.  One big problem is that you are likely to
have broadcasts with all sorts of broadcast addresses.  Suppose that we
have 128.84.253.0 and 128.84.33.0 (netmask 0xffffff00) on the same cable.
Then the host with interface address 128.84.253.3 will occasionally
receive Ethernet broadcasts that contain IP broadcasts with destination
128.84.33.255.  If this is a typical 4.3BSD implementation, it will say
"that's not a broadcast address, so I gotta forward or send an ICMP
unreachable or something".  Result:  every host on 128.84.253.0 replies
at the same time, and you get a big Ethernet collision.  We tried something
like this, and sure enough our SUNs were reporting 70% collision rates!

Another version of the Ethernet meltdown Charles Hedrick so aptly described
in these pages a few weeks ago.
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 15:49:58 EDT
From:      minshall@OPAL.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   Telnet, <CR><LF>, etc.


	(LONG MESSAGE - print and read at your leisure.)

	I have the pleasure of being the gongfermer (aka nightman) for
4.3 telnet and telnetd.  One of my joys is replying to the recent
discussion of same.  Another of my joys is admitting that everything
wrong with 4.3 telnet and telnetd is my fault.

	William R. King started out the discussion asserting that
4.3 telnet was sending \n when the user typed carriage return.  Dave Borman,
from Cray, (who, by the way, spent a LOT of time helping to improve 4.3
telnet/d over the 4.2 versions) suggested that this was unlikely to
be the case.  This is, indeed, unlikely to be the case.

	The "problem", as Steve Alexander (and various others in both
the public discussion, and in private comments) has mentioned, is that
the 4.3 telnetd (the server telnet), on receiving a TELNET <CR><LF>, sends
in a \n towards the application program.

	Now, Mr. John Shriver (jas) has a bit of a flame.  I, personally,
don't agree with the emotion of his flame, but I'm willing to talk
about the philosophy.  If I seem to be a bit derisive, please bear
with me (this is a very sore subject).

	Jas states "In user Telnet, you should send <CR><LF> when the
user types the 'doit!' key."  Now, I would very much like to see
a reference in the RFC (854) to that effect; I won't, though.  I've
looked many times.  Jas, of course, is not the only person who
believes this to be the case.  I don't know jas, but I know and trust
Bob Braden at ISI, and he is as emphatic as jas is about this.  Ken
Pogran also agrees.  So does Stephen Casner (and he quotes chapter and
verse!  Alas.).

	But, honest to god, it isn't in the spec.  The spec talks a lot
about what <CR><LF>, <LF>, <CR><NUL> will do to the printer head.  The spec
does say:  "Even though it may be known in some situations (e.g., with
remote echo and suppress go ahead options in effect) that characters are
not being sent to an actual printer, nonetheless, for the sake of
consistency, the protocol requires that a <NUL> be inserted following a
<CR> not followed by a <LF> in the data stream."  (And, yes, the 4.3
implementations do that.)

	So, I do not believe that <CR><LF> is NECESSARILY what should be
sent when the user hits the "Enter", "Return", whatever, key.

	What I DO believe is that the group of people who believe <CR><LF>
is the way to go are relying on, in many cases, their participation in
"let's define and bring up TELNET" meetings, projects, etc., back when
"everything" was starting.  I really wish these people, all of whom have
much more experience than I in this business, would realize this point.

	So, how does 4.3 telnet (the client side) work?  If remote echoing
is going on, and the user types '\r', we send <CR><NUL>.  If local echoing
is going on, and the user types '\r', we ECHO '\r\n', and send <CR><LF>.

	NOTE:	I think that 4.3 telnet (and I know that 4.3 telnetd)
		is broken in binary mode, sending <CR><NUL> when it
		should send just <CR>.  Null stuffing isn't valid
		in binary mode.

	That is how 4.3 telnet works.

	Now, we slip over to 4.3 telnetd (the server).

	Again, the 4.3 server conforms to the protocol (not out of
ignorance, not out of independence, but out of thought and some
consultation).  When we receive <CR><NUL>, we send '\r' towards
the application program.  When we receive <LF>, we send '\n' towards
the application program.  What do we do when we receive <CR><LF>?
Well, what should we do?  Clearly the user has typed something.  What
they are sending is an "end of line function" sequence (cf the note
from Merton Campbell Crockett to this list); they are signalling
"newline" if you will (and we would).  The Unix "newline" character
is '\n' (NOT '\r').  If the 4.3 server receives a <CR><LF>, we send
a '\n' (newline) towards the application program.

	This is a problem if the user on the client side has no way
of sending <CR><NUL>.  If the client side has no way of sending
<CR><NUL>, then the application program is not going to see what
it would have seen had a '\r' been sent its way (if it could have
noticed a difference; most Unix applications would not notice the
difference [but some do]).

	We could, it is true, have mapped the <CR><LF> to '\r'.
That would also have been within the spec.  It would violate,
somewhat, the philosophy of Unix (that '\n', not '\r', is the newline
character).  If would also mean that anyone unfortunate enough to be
connecting from a client unwilling to send a <LF> alone would face
a problem getting a '\n' send towards their program.

	I hope I haven't offended anyone overly.  I AM pissed off (and
what's wrong with being pissed off?).

	I hope that we can move from "Berkeley is violating the
protocol" (which, except in the case of binary mode mentioned above,
we aren't), to a Unix discussion of "how best could it work interface
to Unix" (since I believe that the discussion of <CR><LF> -> '\n' or
'\r' is a Unix discussion).  Or, to a general discussion of "when
should a client send <CR><LF>, when should it send <CR><NUL>, when
should it send <LF>?" (recently there was some talk about defining
line and character mode; there may be some interaction here).

	In summary:  In client mode, we sometimes send <CR><LF>,
		we sometimes send <CR><NUL>, and we sometimes
		send <LF> by itself.  In server mode, we
		always pad a standalone <CR> with a <NUL>; in server
		mode, we map incoming <CR><NUL> to '\r', incoming
		<CR><LF> to '\n', and <LF> to '\n'.  None of these
		actions violate the letter (or, to my mind, the spirit)
		of the RFC (or the Boland amendment, for that matter).

Greg Minshall

ps -

Dan Hoey feels it is laughable that "if the <CR><LF> is split
across whatever buffer boundary telnetd is using, the code turns it
into <CR> instead of <LF>".  This is not laughable, but IS
embarassing.  The intent of this was to continue to support brain-damaged
4.2 implementations, which (as has been noted time-after-time) send
<CR> when the user types carriage return.

pps -

Those of you who are accepting of this missive may believe I come from
any part of Berkeley you want; however, for the benefit of those who
would use this letter to criticize the "Berkeley clique", I feel you
should know that I have nothing whatsoever to do with the Computer
Systems Research Group [home of Berkeley Unix].

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 87 18:58:41 PDT
From:      Mark Crispin <MRC%PANDA.COM@SUMEX-AIM.Stanford.EDU>
To:        cdc-ddn@DDN3.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SMTP host number notation
The "host number" is simply the IP address expressed as a large decimal
integer.  In general, there is no reason to use it since the domain
literal form is preferable when "going by the numbers".  However, any
SMTP server implementor who fails to implement it should be shot.
-------
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 17:43:21 EDT
From:      ELINSKY@IBM.COM (Jay Elinsky)
To:        comp.protocols.tcp-ip
Subject:   Source routing

Here's a copy of a note I sent to IBMTCP-L, on the subject of source routing
in the IBM TCP/IP code.  My apologies in advance if it shows up twice --
someone else may have also sent it, but it hasn't shown up on our database at
Yorktown.  I want to make sure it shows up on this mailing list, since the
note that started it all appeared here.

Date:     Wednesday, 29 Jul 1987 17:54:27 EDT
From:     Jay Elinsky <ELINSKY@YKTVMX>
To:       <IBMTCP-L@CUNYVM>
Subject:  Source routing

I'm one of the developers of the VM code at Yorktown, and I want to
clarify some possible misconceptions on this subject:

1) We use source routing only on Token Ring.  Even on Token Ring, we can
certainly also route through a router, if the destination host is on
a different net or subnet.  If the destination host is on a different
ring with the same net or subnet number, we do indeed use source routing.
I believe that this is consistent with the architecture of the Token
Ring.  Is it inconsistent with any existing implementation of TCP/IP
over Token Ring?  If so, I'd certainly like to know about it.

2) Re "No RIF field, no function":  If a host is on the same ring, the
ARP code will recognize it, and subsequent packets between the hosts have
no routing field at all.

3) Our TCP/IP certainly is inter-operable with other TCP/IP implement-
ations.  That is our reason for supporting TCP/IP. To repeat what I
said in (1), the source routing issue is only on Token Ring, and to
the best of my knowledge our implementation is consistent with other
TCP/IP Token Ring implementations, and with Token Ring architecture.

4) In the VM code, the Token Ring routing information is kept as part
of the address translation cache.  I think that's logical.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 18:33:57 EDT
From:      dougm@violet.isc.COM ("Doug McCallum")
To:        comp.protocols.tcp-ip
Subject:   Re(2): STREAM, TLI, and (of all things) MAP 3.0

In reply to your message of 31 Jul 87 14:21:22 GMT
-------

 >It seems that AT&T's TLI primitives are not very different from the
 >Berkeley socket calls. For example: poll == select; t_open == socket;
 >t_bind, t_accept, t_connect, t_listen == bind, accept, connect, listen;
 >t_rcv, t_snd == recv/recvfrom, send/sendto; t_snddis == shutdown...

Actually, t_bind == (bind+listen)
	  (t_listen+t_accept) == accept
	  t_connect == connect
	  t_rcv/t_snd == read/write (or send/recv)
	  t_rcvudata/t_sndudata == recvfrom/sendto

The mappings aren't quite exact, but close enough.  With the names being so
similar, expecially t_listen and t_accept, it is easy to assume they work
the same way.

 >Did NIH have something to do with the design of TLI?

Probably a little NIH and a little of trying to generalize a little further.
There are some good ideas, too bad there are some bad ones as well.

 >Actually the real question is:
 
 >If I have an application that communicates with other processes using
 >fairly vanilla socket calls, couldn't I just implement the socket calls
 >for the System V port using TLI calls or at least encapsulate the Unix
 >calls within my own primitives? Or am I missing some basic incompatibility?

Almost.  Without doing some work with which modules are present in the
stream you might have some minor problems.  If you stay with SOCK_STREAM
type usage, you can do pretty well by having the socket emulation library
set the STREAM up to have the read/write interface once the connection is
established.  The SOCK_DGRAM type sockets would be more work since address
information won't be available if you do a read.  In fact the read will fail
if there is address information (in a control portion of a message) and you
haven't setup the read/write interface.  The recv*/send* emulation could
deal with it though.

The main problem is that while sockets preserve file descriptor semantics,
TLI doesn't.  You have to use TLI calls unless you make provisions to use
the read/write interface.  You can't have both at the same time.

 >Oh yes, another question:
 
 >Are there any System V equivalents for the Berkeley Network library functions,
 >such as gethostent and inet_addr, and files such as /etc/hosts and
 >/etc/services? I found no mention in the Network Programmer's Guide or
 >Release Notes. Do I have to pay extra for them?

Nope.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Jul-87 19:28:34 EDT
From:      DHWalker@UCIVMSA.BITNET
To:        comp.protocols.tcp-ip
Subject:   Telnet spooling for Unix

Received: from ORION by UCICP6 with PMDFs; 31 Jul 1987 15:04:01
Received: from localhost by orion.cf.uci.edu id a009621; 31 Jul 87 14:59 PDT
Date: Fri, 31 Jul 87 14:59:55 -0700
From: David Walker <dwalker@orion.cf.uci.edu>

Does anyone know of a filter program for Unix's spooling system which
can make a telnet request for its printer?  We would like to attach
(cheap) serial printers to terminal servers and have them accessible
from our Sequent system (among others).

                                             David Walker
                                             Network Services Manager
                                             UC Irvine

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Jul 87 21:36:42 CDT
From:      David Chase <rbbb@rice.edu>
To:        leong+@andrew.cmu.edu (John Leong)
Cc:        info-vax@kl.sri.com, tcp-ip@sri-nic.arpa
Subject:   Warrantied software?
> For quite a number of organisations, you may well be advised to get
> fully supported and warrantied software from commercial vendors instead.

"_______ is sold as is without warranty as to performance, merchantability,
or fitness for any particular purpose.  The entire risk as to the results
and performance of _______ is assumed by the Licensee." (etc)

Yes sir, you get your money's worth out of those software warranties.  Try
substituting "bridge", "car", or "airplane" for "_______".

David
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 87 20:14:41 GMT
From:      osupyr!hsu_f@ohio-state.arpa  (Frank Hsu)
To:        tcp-ip@sri-nic.arpa
Subject:   Wollongon TCP/IP for AT&T 3B2
I have an AT&T 3B2/300 computer running UNIX System V R3.0, and I installed
the Wollongon TCP/IP software then make it running.

I can do remote login (rlogin), e-mail (mailx), file transfer (ftp) with
IBM 3081 (MVS), 4341 (VM/CMS), Sun Workstation, Pyramid, DEC VAX 11/780
and many other machine.  

This TCP/IP is running fine.  The only two problems are
1) It is trying to communicating to port #513 all the time.
2) It done not accept host names contain a dot (.) when doing e-mail (mailx).

And one more thing that I know is that AT&T is supporting this software, and
I have reported these problems to AT&T.

						Frank C. Hsu
						IRCC
						Ohio State Univ.
						Columbus, Ohio
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 87 23:27:22 GMT
From:      trwrb!ucla-an!medivax!chinson@ucbvax.Berkeley.EDU  (Chinson Yi)
To:        tcp-ip@sri-nic.arpa
Subject:   CMU TCP/IP for VMS
We are trying to bring up TCP/IP on our uVAX running VMS 4.4 and
heard about CMU TCP/IP.  Can someone send me how to get this program.

Also, if someone is running this, I would appreciate any comment
or evaluation on this CMU TCP/IP.

Thank you
Chinson Yi
UCLA, Dept. of Medicine (medivax)
       __
       ||
      ====
      |  |__
      |  |-.\
      |__|  \\
       ||   ||
     ======__|
    ________||__
   /____________\ (c)

END OF DOCUMENT