The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for October 1986 (131 messages, 66331 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/10.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-Oct-86 05:59:33 EDT
From:      raklein@MITRE.ARPA (Richard A. Klein)
To:        mod.protocols.tcp-ip
Subject:   Re: Do we need another protocol?

I'm getting tired of listening to people pontificating DoD policy.
The reason why that particular organization in the U. S. Army did not
choose the MIL-STD protocol suite (TCP/IP) is because they are not
well informed on the existance and benefits of the DoD protocol suite.
In addition, the U. S. Army organization in charge of developing
standards is not well informed and has been remiss in general with
regard to getting standards out to the rest of the Army.  JTC3A's lack
of progress in developing protocol standards for tactical applications
for all of DoD has further hampered the standardization effort.  But
the real crux of the matter is that WE are responsible, as
consultants, engineers, researchers, etc., for insuring the
recommended use of the DoD MIL-STDs when appropriate.

I'm currently supporting the Army's effort to "go ISO."  This means
that they want a "militarized" ISO protocol suite right-a-way, and
they don't want to be bothered by an intermediate standard such as
TCP/IP (?!).  Some how or the other, we will make the best effort to
direct them towards the right standards for the right times.  I have
found that the most convincing arguments are demonstrations to the
sponsor of the real benefits of using TCP/IP now, ISO later, when it
is tested and proven.  By the way, watching the bureaucrats yell
policy at each other has proven to us, without a doubt, that it won't
get you anywhere.

Richard

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Wed 1 Oct 86 12:41:40-EDT
From:      Dennis G. Perry <PERRY@VAX.DARPA.MIL>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        perry@VAX.DARPA.MIL
Subject:   Congestion in the Arpanet


There has been quite a bit of conjecture on what is happening
in the Internet and what are the reasons for the performance that
people are seeing.  I have been trying to understand these issues
myself and asked BBN to provide me with some information.  Attached
is some of that information.  I hope it raises other questions and
answers a few.

dennis
                ---------------




----- Forwarded message # 1:

Received: from cc5.bbn.com by .J.BBN.COM id a021878; 30 Sep 86 23:35 EDT
To: jburke@cc5.bbn.com, mlevandowski@cc5.bbn.com, rgrenier@cc5.bbn.com, 
    sblumenthal@cc5.bbn.com, mckenzie@cc5.bbn.com, pogran@cc5.bbn.com
To: prishivalko@cc5.bbn.com, dperry@vax.darpa.mil
cc: mayersoh@cc5.bbn.com, jwiggins@cc5.bbn.com, cgreenleaf@cc5.bbn.com, 
    mprimak@cc5.bbn.com, fserr@cc5.bbn.com, scohn@cc5.bbn.com, 
    hinden@cc5.bbn.com
Subject: arpanet congestion
Date: 30 Sep 86 23:16:58 EDT (Tue)
From: Jeff Mayersohn <mayersoh@cc5.bbn.com>


     For the last month, a large number of PSNs in the Arpanet have
been reporting symptoms of congestion to the network monitoring
center.  These reports, or "traps," have been accompanied by an
increasing number of user complaints.  In order to deal with the
problem of network congestion, we have been pursuing a number of
avenues at BBNCC.  This note summarizes the current state of our
investigations and makes a number of specific recommendations. 

     First, a little background.  The Arpanet topology is largely
unchanged since the physical split of the Arpanet into the Arpanet and
Milnet in 1984.  The topology of the post-physical-split Arpanet was
actually designed from data which was collected before the earlier
logical split of the two networks.  In the past year, the network has
shown a significant increase in traffic.  A five-day average of
network traffic showed an internode traffic rate of 140 Kbps in June
of 1985 and an internode traffic rate of 230 Kbps in March of 1986.
(The traffic growth had, in fact, leveled off over the summer of 1986
but we suspect that traffic has grown even more since the start of the
academic year.)  The network has recently been redesigned to
accommodate NSF hosts, but these new resources have not yet been added
to the network. 

     Marianne Gardner has observed some very interesting trends in the
statistics that we have collected recently.  First, a very small
percentage of host pairs account for a very large percentage of the
network traffic.  More than 80% of network traffic is contributed by
600 host pairs (out of 2596 communicating pairs).  Some 60% of the
traffic is contributed by 100 pairs.  Second, gateway traffic
dominates network traffic.  86% of Arpanet traffic has a gateway
as either the source of destination.  52% of network traffic is
between gateways.  

     Our immediate focus over the last few weeks has been to
concentrate on topological modelling in order to recommend a small
number of changes which would bring network resource usage to
acceptable levels.  This modelling was based upon the peak hour
traffic in late June, the last month during which a global network
statistics collection was performed.  The measured June traffic was
increased by 50%.  This number was based upon the recent growth in
network traffic and the ratio of the peak hour traffic to the peak
minute traffic.  The assumption is probably conservative, which is
good. 

     The modelling work was done by Peg Primak, whose report is
contained in the following.  As of June, 1986, the Arpanet contained
47 nodes and 63 links.  Two of these nodes have since been retired
(SAC2 and USC) but were retained in the current model with all USC
traffic re-routed to node 121.  Our routing model shows single hour
maximum link utilization of 75% (on UWisc-Roch) and maximum node
utilization of 69%.  Even with the UWisc-Purdue link restored, the
maximum link utilization is still 72% and the maximum node utilization
is 69%.  (The Wisconsin to Purdue link was temporarily removed from 
the network a while ago.)

     To alleviate the worst of these problems, we considered adding a
link from MIT77 to SRI51.  The addition of this link reduces maximum
link utilization to 58% (on the new link), with only two other links
having utilizations over 50% (53% and 51%).  Node utilization remains
unchanged.  The network diameter is reduced from 10 to 9 by the
addition of this link.  As these results show, a link between MIT77
and SRI51 would substantially improve Arpanet performance, and would
become one of the most heavily utilized links in the network. 

     Node utilization is quite heavy on several nodes.  Normal
utilization over seven minute intervals seems to be between 30% and
60% for all of the following nodes: ISI27, UCLA, RCC5, and UWISC.
With the MIT-SRI link added, SRI51 will join this group.  Measurement
data show that each of these nodes experiences times of very heavy
utilization (15 minute averages of 60% to 70%, 7 minute averages of
87%).  Based on the June data, either nodes should be added at these
sites or the five nodes at these sites should be upgraded to C/300s. 

     We assume that the addition of trunk bandwidth will take a while.
There are a number of other actions which we would like to take.
First, TAC 113 should be installed immediately in the Arpanet.  This
provides for two changes that should reduce congestion.  First, the
release bundles more characters into single packets, thereby reducing
the number of bits and packets required to send a given unit of Telnet
data.  TAC 113 also modifies the TCP retransmission timers.  We
probably get the wrong kind of feedback when the network slows down.
If data is delayed due to network congestion, we suspect that this
gives rise to TCP retransmissions which exacerbate the original
problem. 

     Bob Hinden of our gateway group tells me that, in the next two
weeks, we will conduct an experiment which will make the Wideband
Network look more favorable to the internet routing in the Butterfly
gateways.  This will cause some gateway-to-gateway traffic to move
from the Arpanet to the Wideband Network.

     We have observed that, when network links get heavily saturated,
the network routing algorithm becomes a bit too dynamic, trying to
find excess capacity which does not exist.  The effect of the
resulting oscillations in network routing sometimes works to the
detriment of network performance.  There is a simple fix to this,
i.e., we can easily make all three cross-country paths look equivalent
to the routing algorithm.  This results in the proper sort of
load-sharing. 

     There is still the possibility that we are running short of
end-to-end resources.  We are currently measuring the utilization of
these resources to see whether this is the case.  If we are short of
these resources, there may be easy remedies to this in the PSN
software. 

     Our efforts over the last few weeks have concentrated on the
modelling work.  We have not had the opportunity to accumulate or
study global network statistics collection in order to understand what
has changed in the last month.  John Wiggins and Clive Greenleaf have
begun this collection today.  Simple questions which should be
answered are: 1) where has traffic increased?  2) are gateways using
the network differently?  3) are we seeing large amounts of internet
control traffic as we have in the past?  3) would the addition of
mailbridges improve the situation?  5) should homings of hosts to
mailbridges be changed? 


     In summary, we should pursue the following: 

1) A link from MIT to SRI51 should be added. 

2) Node capacity should be added at ISI27, UWISC, RCC5, UCLA, SRI51

3) The planned addition of resources should be accelerated. 

4) TAC 113 should be installed. 

5) The network parameters should be adjused in order to result in more
even sharing of the cross-country bandwidth, should statistics confirm
that routing oscillations are occurring. 

6) The Wideband Network experiment should be conducted as soon as
possible. 

7) Additional statistics should be collected in order to shed light on
the underlying causes of the congestion.  We will let results be known
as soon as we have them.

8) The Purdue to Wisconsin link should be restored asap.
 

----- End of forwarded messages

-------
-------
-------
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 13:40:45 EDT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        mod.protocols.tcp-ip
Subject:   Do we need another protocol?


Re: record-level access in TCP

This has come up before as being seriously lacking in other contexts.

It may be a can of worms due to the nature of heterogeneous networks,
usually the person calling for it is thinking of just THEIR record
level access (eg. VMS/RMS.) My usual reaction is that this problem has
not been adequately solved for magnetic tapes across heterogeneous
systems so I suspect there is a nut there to crack, it's not like tape
users never thought of it.

Even if OpenNet gets you this service to another OpenNet/Intel310
host, I doubt it helps you much with a PDS file on the MVS system
down the hall. It just solves the easy, short term problem.

I would suggest the community start looking hard at how far NFS/RPC/XDR
from SUN (and, as we all know, being adopted as a layered protocol on
TCP/UDP/IP by almost every major computer vendor) can be used to solve
the problem. It's not really 'record' level access, the question is better
put as:

	"How in general can I create a network I/O stream
	 which, rather than bytes, uses an arbitrary structured
	 data type, with a file offset calculation, as a unit of
	 transfer?"

Perhaps just semantics but I think it brings one a little closer to
understanding why something like XDR/RPC already addresses this
problem to a large extent and working from that base, where weaknesses
are perceived, might be the most profitable route to a solution (lord I
sound pedantic, sorry...)

Essentially (for those who haven't looked at the SUN protocols) one
sits down (they have already) and defines a network representation
for various primitive types (eg. byte order and format of integers).
Then a method for constructing arbitrary data types out of those as
n-tuples. Then a protocol for exchanging what you have in mind (as
a trivial example exchanging a fortran format string would be close)
and finally a remote procedure call protocol for specifying various
remote operations.

To stave off the flood of "XYZ system has been doing that for years",
yes, we know, but XYZ system is not licensable on our machines, is it?
The XDR/RPC protocols (protocols != code) are in the public domain.

And yes, I don't think it would be a good idea to put this into FTP
until this layer is defined. At some later date it might be clear
how these mechanisms can best be utilized in an extension to FTP for
some subset, but I doubt FTP is designed to support such generality.

	-Barry Shein, Boston University

P.S. I have no economic interests in any of this, if I did I'd probably
be rich and out spending my money instead of typing this stuff in...

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 14:12:53 EDT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        mod.protocols.tcp-ip
Subject:   Peace fullness.


>   As a developer it IS my responcibility to produce a product that my
>clients desire and to develop new features and approches.
>
>   I have done just that, but I am afraid to market it. Why ? Because the
>Universities will produce a public (or very cheap) version and have their
>name behind it! All my time, effort and MONEY will be wasted.

I am not sure this is the right list to address this issue although
I am not sure what the right list is. Apologies in advance.

Your problem is ubiquitous to the software industry.

It's caused by a conception of software as merchandise, a comfortable
conceptualization in an economy that by and large likes to break things
down into such catagories.

Unfortunately, software does not fit that paradigm very well as you
have discovered. It is closer to a service than a product. Recordings
and books have various similarities, but in general a song by a
particular artist is not easily replaced by a very similar song by a
very similar artist, so copyright is effective. That is, software is
too easy to duplicate and its function is fairly specific, thus my
TCP program that I give away for free may very well wipe out your TCP
program that you sell. I doubt too many people would like to have a
recording of something that sounds a lot like me singing what might
be a Michael Jackson song, or a story I've written very much in the
style of Ernest Hemmingway (there is a contest however...)

If one accepts the problem rather than fights it, one might come to
the conclusion that the software should be sold for a nominal fee and
the real product would be continuing support as a subscription. This
most Universities have little interest in providing. It's probably not
a bad business either tho perhaps not as trivial as sitting down,
writing a program, selling a zillion copies and then never incurring
another cost except that of copying floppies and mailing them out.
You might actually have to work for a living!

It's no wonder that racket has a few weaknesses although I don't doubt
it would be (and has been) massively profitable.

	-Barry Shein, Boston University

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 15:36:40 EDT
From:      ROMKEY@XX.LCS.MIT.EDU (John Romkey)
To:        mod.protocols.tcp-ip
Subject:   Re: MIT pcip and 3com board

If the 3C501 is connected to the ether via a DELNI the VAX has an
Interlan transceiver, you will probably have problems. I've heard
reports from a number of places that 3COM cards connected to DELNIs
can't reliably talk to a number of vendors transceivers.
(these are only *rumors*, mind you...)

The problem is supposed to be that the ethernet chip used on
the 3C501 doesn't grok heartbeat, and you can't get DELNIs
not to do heartbeat.
				- john
-------

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Wed, 01 Oct 86 18:40 PDT
From:      Todd Booth 213-825-1933 <CSDCTGB@UCLA-CCN.ARPA>
To:        Submit to TCP/IP <tcp-ip@sri-nic.arpa>
Subject:   Re: Implementation list
> Shouldn't this (in theory) be part of the NIC's
> tcpip-implementations.txt, John Romkey <ROMKEY@xx.lcs.mit.EDU>
> file?

The file has been renamed Netinfo:vendors-guide.doc

-todd

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 15:51:00 EDT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        mod.protocols.tcp-ip
Subject:   SMTP, 2600, and the security of mail


    Date: Monday, 29 September 1986  18:17-EDT
    From: Stu Grossman <GROSSMAN@Sierra.Stanford.EDU>

    You could (marginally) increase the security of SMTP traffic by having
    SMTP servers only accept connections from a 'privileged' remote socket.  

Bad idea.  Nobody has ever agreed on what a "priviledged port" is.
Berkeley has used that concept for some of their net code (I'm
thinking of LPD in particular).  It doesn't add any security when
talking to TOPS-20 or ITS, it's just a pain in the butt because I
can't let the TCP software do the local port multiplexing for me.

This whole discussion seems pretty pointless, since everybody accepts
the need for mail relays and you can't ever possibly verify what
happened on the other side of the mail relay.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 16:00:00 EDT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        mod.protocols.tcp-ip
Subject:   SMTP, 2600, and the security of mail


    Date: Tuesday, 30 September 1986  13:29-EDT
    From: The lost Bostonian <gds@spam.istc.sri.com>
    To:   header-people@mc.lcs.mit.edu, tcp-ip@sri-nic.arpa

    If it is true that all IP implementations enable a server program to
    determine the IP address of its peer, then the HELO command, and its
    response could be eliminated, which would save us a few bytes.

You are assuming that it is always possible to translate addresses to
names and vice versa.  Unfortunately, there are some people out in the
world running domain nameservers who are totally clueless about what
they are doing, and there are others who have the misfortune to be
stuck behind a losing gateway or otherwise be unreachable much of the
time.  Do you really want to make it impossible to receive mail from
some host because a third party is broken?  Or have to put numeric
addresses into the Recieved headers?

The answer is to fix the silly net, not throw away features to save
two IP packets.

--Rob

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 16:18:00 EDT
From:      jrodrig@EDN-VAX.ARPA (Jose Rodriguez)
To:        mod.protocols.tcp-ip
Subject:   Sun NFS RFC


And if there are changes to it, what would happen to all those 
implementations? RFC?, ya...

Jose
jrodrig@edn-vax

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 19:23:49 EDT
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Re:  Why is the ARPANet in such bad shape these days?

Many sites with really large sets of LANS (including MIT and BRL)
run dedicated IP gateways as their attachment to the IMPs.
In these cases, all traffic on those IMP ports is either user
traffic or EGP.

BRL-GATEWAY and BRL-GATEWAY2 are pretty high up as the largest
source of packets on the MILNET, today.  When our Cray-XMP48
comes online on 2-November, I expect our MILNET trunks to melt.
	-Mike

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 19:55:50 EDT
From:      GROSSMAN@SIERRA.STANFORD.EDU (Stu Grossman)
To:        mod.protocols.tcp-ip
Subject:   Re: SMTP, 2600, and the security of mail

> You could (marginally) ...

That's why I said "marginally".  Yes, LPD has this problem, but it's not
so simple.  LPD can be told to accept print requests only from certain hosts.
So now you have to:
        1) successfully imitate another host, and
        2) declare yourself as the appropriate port type
So that you can send bogus print requests to an lpd.

Yes, the 'privileged' port number stuff in LPD is quite naive.  However,
as long as point 1 (above) is quite difficult to do, LPD can be pretty
safe from bogus print requests.
-------

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 21:40:00 EDT
From:      CSDCTGB@UCLA-CCN.ARPA (Todd Booth 213-825-1933)
To:        mod.protocols.tcp-ip
Subject:   Re: Implementation list

> Shouldn't this (in theory) be part of the NIC's
> tcpip-implementations.txt, John Romkey <ROMKEY@xx.lcs.mit.EDU>
> file?

The file has been renamed Netinfo:vendors-guide.doc

-todd

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 1986 1047-PDT (Thursday)
From:      Bill Croft <croft@safe.stanford.edu>
To:        ehrlich%psuvax1.bitnet@WISCVM.WISC.EDU
Cc:        tcp-ip@sri-nic.ARPA, info-vax@brl.ARPA, croft@safe.stanford.edu
Subject:   Re: BOOTP daemon for BSD 4.x
Client and server implementations of BOOTP (Bootstrap Protocol, RFC 951)
are available via anonymous ftp from host safe.stanford.edu, in the files:

	pub/bootp.client.shar
	pub/bootp.server.shar

Both implementations are in C, the server code for 4.2 BSD, the
client code resides in PROM in our campus gateways/tips (multibus
68000 systems).  The client autoconfigures for a number of different
ethernet board manufacturers (3COM, Interlan, Xerox).

The BOOTP protocol is defined such that clients can boot themselves
even when: (1) the client is on an ether segment without a boot server
host.  (2) the client doesnt yet know its own IP address.

	--Bill Croft, Stanford Univ., CSLI
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Oct 86 10:35:54 EST
From:      "Thomas Narten" <narten@purdue.edu>
To:        amdcad!phil@decwrl.DEC.COM (Phil Ngai)
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: MIT pcip and 3com board
This is probably not the problem, but....

We recently discovered that the implementation of ARP under pcip is not
quite the same as that on other machines, such as 4.2/4.3 Unix. The ARP
we were running under 4.2 on our VAXes came from Sun; we were not
running the vanilla 4.2, so I can't say what 4.2 ARP does.

When pcip recieves an ARP packet, the first thing it does is check the
target protocol address against its own. If they do not match, the
packet is tossed without further processing. 4.3 Unix on the other
hand, checks first to see if the sender protocol address in the reply
packet matches an entry in its ARP cache. If it does, it updates the
entry. 

In our case, we had a machine that sent ARP replies, using the same
addresses in the sender and target fields. On Unix machines, this
worked. Unix would add an entry (marked incomplete) for the Internet
address it wanted, send out an ARP request, and the machine would
answer. Even though the ARP reply that was received did not have the
requesting machines address in the target fields, the entry was
correctly installed.

The pcip machine in the other hand would toss the reply, thinking it
was not the reply is was looking for.

Thomas
----------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Oct-86 11:33:44 EDT
From:      GOWER@D.ISI.EDU (Neil E. Gower)
To:        mod.protocols.tcp-ip
Subject:   Re: Congestion in the Arpanet


Dennis, thanks for the copy of BBNs progress and plan of attack.  We are
having trouble understanding why the busiest nodes are not in the middle
of the cross-country paths (SAC, TEXAS and COLLINS (ours)).  Or at the
entrances to those paths.  The only one of the four mentioned by BBN,
which seems to fit the "cross-country bottleneck" is UWISC.

There also seems to be no explanation why a PSN cannot give reasonable
response between two of its own nodes.  We see just as poor (or worse)
service between equipment in the same room here as we do between here
and D.ISI.EDU (ISI27).  Maybe its because our packets are going to ISI27
or somewhere else first.

It does seem that all four of the PSNs mentioned are in areas where
heavy (not necessarily cross-country) traffic would occur.  This would
indicate problems in the areas of shortages of packet buffers and/or
virtual circuits and/or slowness in setting up virtual circuits.

I agree that we have an ONION of problems, but wouldn't it make sense to
resolve the ones that are "localized" to one PSN first?

Regards,
Neil Gower
-------

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 1986 11:33:44 EDT
From:      Neil E. Gower <GOWER@D.ISI.EDU>
To:        Dennis G. Perry <PERRY@VAX.DARPA.MIL>
Cc:        tcp-ip@SRI-NIC.ARPA, GOWER@D.ISI.EDU
Subject:   Re: Congestion in the Arpanet

Dennis, thanks for the copy of BBNs progress and plan of attack.  We are
having trouble understanding why the busiest nodes are not in the middle
of the cross-country paths (SAC, TEXAS and COLLINS (ours)).  Or at the
entrances to those paths.  The only one of the four mentioned by BBN,
which seems to fit the "cross-country bottleneck" is UWISC.

There also seems to be no explanation why a PSN cannot give reasonable
response between two of its own nodes.  We see just as poor (or worse)
service between equipment in the same room here as we do between here
and D.ISI.EDU (ISI27).  Maybe its because our packets are going to ISI27
or somewhere else first.

It does seem that all four of the PSNs mentioned are in areas where
heavy (not necessarily cross-country) traffic would occur.  This would
indicate problems in the areas of shortages of packet buffers and/or
virtual circuits and/or slowness in setting up virtual circuits.

I agree that we have an ONION of problems, but wouldn't it make sense to
resolve the ones that are "localized" to one PSN first?

Regards,
Neil Gower
-------
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Thu 2 Oct 86 12:38:35-EDT
From:      Dennis G. Perry <PERRY@VAX.DARPA.MIL>
To:        GOWER@D.ISI.EDU
Cc:        PERRY@VAX.DARPA.MIL, tcp-ip@SRI-NIC.ARPA, perry@VAX.DARPA.MIL
Subject:   Re: Congestion in the Arpanet
Niel, one reason collins may not be as saturated is that you
seem to be more isolated and in a multihop link across the country.
The only direct E-W link is USC-DARPA.  The E-W link involving
Collins starts at SRI2-Collins-Texas-Bragg-Dcec20.  The other E-W link
is UCLA-Texas-Bragg-DCEC20.  The third E-W link is LBL-Utah-SAC-Uwisc-
Uroch-RCC5.  So I would assume the NE bound traffic would prefer the
Norther route, and Mid-Atlantic bound traffice would prefer the direct
route.

As to why PSNs have problems between two of its own hosts, I have no
idea, but have asked the question.

dennis
-------
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Oct-86 17:59:44 EDT
From:      leong@ANDREW.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   Re: MIT pcip and 3com board


I have no experience with the newer 3COM short dumb card. However, with the
full length card, we have experience similar odd and flaky behaviour quite a
while back (It work with some machine but not others). The problem turns out
to be incompactibility between our transciever and the card. 

Most of our transciver are the Ethernet Rev 1 varitey. The 3COM card uses the
SEEQ DQ8023 transceiver chip and is, by default, 802.3 variety. According to
the SEEQ engineering sheet, one can select the SEEQ chip to work as Rev 1
mode by grounding PIN 10 (notch to your left : bottom set of pins : wire the
first and last pins togther). We did that to all our 3COM board and the
problem went away. We suggested to 3COM that they should provide a jumper but
I don't think they have done anything.

But, there again, that may not be your problem .....

John Leong
leong@andrew.cmu.edu

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Oct-86 18:02:59 EDT
From:      leong@ANDREW.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   more .. Re: MIT pcip and 3com board

More ....

By the way, we have the same problem with the NI1010A.  Again, you have to
set the transciever chip on that board to match the Ethernet Rev of your
actual transceiver. Otherwise, you can get flaky behaviour.

John Leong
leong@andrew.cmu.edu

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Oct-86 18:30:49 EDT
From:      leong@andrew.cmu.edu (John Leong)
To:        mod.protocols.tcp-ip
Subject:   Re: Ethernet carrier sense during transmit

Re :

".....  Ethernet assumes a certain maximum transceiver cable length and a
certain minimum signal propagation velocity .... The Codenoll system alters
the parameters which permit the monitoring of carrier.  As such, calling it
"Ethernet" or "Ethernet compatible" could be misleading and could cause
network failures which are hard to diagnose such as your case. ...... "

I am curious as to how the Remote LANBridge function in conjunction with the
DEC remote repeater.  Does the AMD chip inside the LANbridge, pointing to the
direction of the long fibre link, programmed to carry out the
CarrierSenseTest ?  

Furthermore, it is my contention that doing a CarrierSenseTest is probably a
good thing but the timing is questionable bearing in mind that the 50 meter
transciever cable distance is really a function of DC power attenuation
between the controller an the transceiver. If the tranceiver is locally
powered, that distance limitation would not have applied. The only relevant
number will then be the 51.2 microseconds (512 bits) slot time.

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Oct 86 19:38:37 EDT
From:      Jim Rees <apollo!rees@EDDIE.MIT.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: SMTP, 2600, and the security of mail
    You could (marginally) increase the security of SMTP traffic by having
    SMTP servers only accept connections from a 'privileged' remote socket.  

This doesn't increase security, it decreases it.  It fools the system
administrator into thinking that there is such a thing as a "privileged
remote socket", when in fact there isn't, and it makes it necessary for
the guy who is writing and debugging an smtp client to get superuser
privileges on those machines that do implement 'privileged' local ports.
Like the "communications privacy act", "privileged ports" are a sham
that just fool people into thinking things are secure when they aren't.
-------
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 1986 23:15-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   IP source routing questions
After looking through a couple of IP specs and a couple of IP
implementations, I still have a shaky understanding of how source
routing works.  Assuming host A wants to send a datagram to host D,
source-routed through gateways B and C,

     host A           gate B           gate C           host D
    +------+         +------+         +------+         +------+
    |      |         |      |         |      |         |      |
    |    A1|-------->|B1  B2|-------->|C2  C3|-------->|D3    |
    |      |  net 1  |      |  net 2  |      |  net 3  |      |
    +------+         +------+         +------+         +------+

where A1, B1, B2, etc. are IP addresses.  I think that the upper layer
protocol in host A should pass the following IP header values to the
IP layer:
             source:A1  destination:B1  route:B1,C2,D3  offset:4

where offset is the value of the third byte of the source route option.
Then I expect the datagram to contain the following values when it is
transmitted:

on net 1:    source:A1  destination:B1  route:A1,C2,D3  offset:8

on net 2:    source:A1  destination:C2  route:A1,B2,D3  offset:12

on net 3:    source:A1  destination:D3  route:A1,B2,C3  offset:16

Is this right?  Perhaps the source address changes at each hop?  Or the
destination address remains constant?  Or there should only be two
addresses in the route option?  Or the offset values should be 4 less?

Methinks the specs could be clearer on this.

Steve Deering
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Oct-86 00:02:20 EDT
From:      GLM@IPGUNIV.BITNET
To:        mod.protocols.tcp-ip
Subject:   booking TCP-IP mailing list

I wuould like to be registered in the TCP-IP mailing list.
Sincerely
              Gianfranco Galmacci

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Oct 86 00:14:06 edt
From:      jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP for HP-UX on HP9000s
I have heard of this, but one of my contacts says that her HP salesman
can only offer her a networking package running on Ethernet which
isn't TCP/IP now, but will become TCP/IP later.  My own initial
attempts to find out via HP salespeople haven't produced anything yet.

I am interested in 1) Part numbers and descriptions of HP networking
offerings for the 9000 under HP-UX and otherwise, and 2) discussion of
how the offerings are/aren't TCP/IP.  Replies to the address below,
and I will summarize to the list if requested.

jbvb@ai.ai.mit.edu
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Fri 3 Oct 86 01:48:28-EDT
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        hedrick@TOPAZ.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA
Cc:        JNC@XX.LCS.MIT.EDU
Subject:   Re: odd routings
	I have a few quick comments on some recent messages; I'm going
to be a good citizen and package them togther in one reply!

	1) The extra hop problem in EGP. (Enter broken record mode.) I've
explained this several times, but let me try again quickly. This is a
problem with *GGP* (NOT EGP), the routing protocol run between the core
gateways. It was designed before EGP, and thus does not interoperate
correctly with it. If MIT has core gateway A as an EGP peer, and Rutgers
has a peer core gateway B, then there is no way (using GGP) for A to
inform B that to get to MIT it can go direct; both B and all its clients
(e.g. Rutgers) think they have to go through A.  This is the cause of the
funny routes with routes to CMU, MIT, etc.  Your gateway is just fine, and
it's not EGP's fault either. (Leave broken record mode.) The extra hop
problem will only be solved when GGP is retired; i.e. when the PDP11 core
gateways are replaced by Butterflys, probably. The extra hops probably are
a significant gratuitous strain on the system.

	B) Ping wars between gateways might be causing problems if BBN
never installed the patch to add more connection blocks (don't worry if
you know what this is), but if that patch is in it shouldn't be a problem.
Can anyone from BBN clue us in? I saw a note in a recent message from BBN
which talked about installing a 'performance improvement' patch to help
with the recent problems; are they referring to the increased number of
connections blocks? If not, what?

	C) "Mail's the culprit." One thought at MIT was that mail was
responsible for the bulk of our outgoing traffic. Measurements of a day's
traffic indicated that SMTP accounted for 35% of the packets and only 27%
of the data through the gateway. (These numbers do not count all traffic
from the MIT complex, since some of our biggest timesharing machines are
on the ARPANet directly, and these figures count only traffic from the MIT
net. The traffic mix on the timesharing hosts might include more mail,
which would bias the whole figure.) Still, these numbers are a long way
from indicting Mail as the culprit in the congestion. Does anyone else
have any numbers on traffic breakdown by types?

	Noel
-------
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Oct 86 09:38:59 -0700
From:      Marshall Rose <mrose@nrtc-gremlin>
To:        Barry Shein <bzs@bu-cs.bu.EDU>
Cc:        WANCHO@simtel20.ARPA, TCP-IP@sri-nic.ARPA
Subject:   Re: Do we need another protocol?
    Well, the XDR/RPC isn't the only public-domain one around.  The
    ISO/CCITT people have ASN.1 (similar to XDR) and ROS (simlar to RPC)
    which do roughly the same thing (but differently of course).  ASN.1
    stands for abstract syntax notation, and ROS stands for remote
    operations.  My (limited) understanding of XDR/RPC indicates that
    ASN.1 and ROS are somewhat more general, though both get the same
    thing done.  As you'd expect, since I give away ISODE (an ISO
    development environment for TCP) for free, I'm biased towards the
    ISO approach.  

    The big win, regardless of the brand of universal-data-exchange-format
    you use is that we can finally get away from the $1.10 netascii
    approach for client-server interactions that we've seen for the last
    10 years.  

    The second big win, which is only now getting attention is that we
    are now a step closer generate program fragments from the data
    representation specifications.  I know that in the current/next
    release of NFS, this capability exists.  In ISODE, there's a yacc
    spin-off called pepy, which reads your instrumented formal spec and
    writes a code fragment that parses the ASN.1 structures into your
    own internal-form.  I've used pepy on four projects now, and each
    time it was a major, major win.

/mtr

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 1986 08:19:29 PDT
From:      Dan Lynch <LYNCH@B.ISI.EDU>
To:        munnari!moncskermit.oz!john@SEISMO.CSS.GOV (John Carey)
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@B.ISI.EDU
Subject:   Re: TCP/IP for Burroughs
John,  You should contact Joe Gibson at 703-847-2305 for info on
Burroughs TCP/IP.  He is the program manager for them (SDC)
on this.

Dan
-------
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Oct-86 10:05:19 EDT
From:      tmallory@ccv.bbn.com
To:        mod.protocols.tcp-ip
Subject:   New gateway software installed

The seven gateways between the Arpanet and the Milnet were loaded with
version 1008.1 software yesterday afternoon(10/2).  The most important
change is the increase from 150 to 300 in the number of networks handled
by the routing module.  Several other changes were made to improve the
behavior of the gateways in the face of severe network congestion.
The 300-network software is (has been) running in all of the EGP
servers.

Tracy Mallory
BBNCC
-------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Oct-86 11:19:29 EDT
From:      LYNCH@B.ISI.EDU (Dan Lynch)
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP for Burroughs

John,  You should contact Joe Gibson at 703-847-2305 for info on
Burroughs TCP/IP.  He is the program manager for them (SDC)
on this.

Dan
-------

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 1986 1430-PDT (Friday)
From:      Barbara J. Pease <bjp%ulana@mitre-bedford.ARPA>
To:        tcp-ip@sri-nic.ARPA
Cc:        bjp@mitre-bedford.ARPA
Subject:   New version of the ULANA Specifications

This noice is to announce that a new version of the ULANA Specifications has
been released and now is available at the ulana ftp site.

		address:	mitre-b-ulana.arpa
		user:		guest
		password:	anonymous
		pathname:	/usr/mitre/guest/ulana.specs

Any comments about the specifications should be mailed to:

		ulana@mitre-bedford.arpa

General correspondence should be mailed to:

		bjp@mitre-bedford.arpa

						bj Pease














-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Oct 86 15:48 PDT
From:      Todd Booth 213-825-1933 <CSDCTGB@UCLA-CCN.ARPA>
To:        Submit to TCP/IP <tcp-ip@sri-nic.arpa>
Cc:        munnari!moncskermit.oz!john@seismo.CSS.GOV(John Carey)
Subject:   RE: TCP/IP for Burroughs
> Does anyone know of a TCP/IP implementation for the B7800?

I don't think so.  At least I didn't find it in the dataset,
sri-nic netinfo:vendors-guide.doc  For anyone who would like
to know what other files are available (and has FTP) the index
is kept as netinfo:00netinfo-index.txt

-todd

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Oct 86 17:14:43 edt
From:      gr@bnl.ARPA (George Rabinowitz)
To:        tcp-ip@sri-nic.ARPA
Subject:   TCP-IP mailing list
	I would like to be registered in the TCP-IP mailing list.
			Sincerely
				George Rabinowitz
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Oct 86 20:20:37 pdt
From:      amdcad!phil@decwrl.DEC.COM (Phil Ngai)
To:        @po3.andrew.cmu.edu:leong@andrew.cmu.edu
Cc:        charlie@decwrl.DEC.COM, rpw3@decwrl.DEC.COM, tcp-ip@sri-nic.ARPA
Subject:   Re: Ethernet carrier sense during transmit
> ".....  Ethernet assumes a certain maximum transceiver cable length and a
> certain minimum signal propagation velocity .... The Codenoll system alters
> the parameters which permit the monitoring of carrier.  As such, calling it
> "Ethernet" or "Ethernet compatible" could be misleading and could cause
> network failures which are hard to diagnose such as your case. ...... "
> 
> I am curious as to how the Remote LANBridge function in conjunction with the
> DEC remote repeater.  Does the AMD chip inside the LANbridge, pointing to the
> direction of the long fibre link, programmed to carry out the
> CarrierSenseTest ?  

First a disclaimer. I do not represent the company in this forum. I am
only stating an opinion based on my understanding of networks. Further
more, I do not know how the DEC LAN Bridge 100 operates.

The LANCE data sheet says it wants to see carrier during a
transmission.  If it ever sees a loss of carrier, it will set a status
bit, bit 11 (LCAR) in Transmit Message Descriptor 3 (TMD3). It will
continue to transmit the whole packet until done. This seems similar
to its handling of SQE. (lack of SQE sets a bit in a register but does
nothing else.) Conditions are detected and available for interrogation
by software but as little of the protocol is enforced by hardware as
possible, where this does not put an undue burden on software.

DEC probably just ignores LCAR on the LANCE which drives the fiber
interface.

By the way, I heard a very clever use of the LANCE. In a bridge, it
would be fair to get more of the bandwidth than a normal station gets.
You can disable the retry on a LANCE and implement your own truncated
binary backoff with shorter time constants in software.

> Furthermore, it is my contention that doing a CarrierSenseTest is probably a
> good thing but the timing is questionable bearing in mind that the 50 meter
> transciever cable distance is really a function of DC power attenuation
> between the controller an the transceiver. If the tranceiver is locally
> powered, that distance limitation would not have applied. The only relevant
> number will then be the 51.2 microseconds (512 bits) slot time.

Yes, there are many ways to break the Ethernet configuration rules and
(temporarily) get away with it. Actually, the 50 meter transceiver
cable distance is due to both DC and AC signal attenuation. The AC
signal attenuation is, in fact, a more severe requirement.

			Belden 9891:
DC resistance	 			10 MHz attenuation
9.3 ohm/1000feet			2.1 dB/100 feet

			Ethernet spec:
4 ohms max				3 dB max

			Allowed length:
4000/9.3 =				3/2.1 =
430 feet roundtrip =			143 feet
215 feet
(ignoring connector resistance)

50 meters is 164 feet.

But I digress. The point is, given two incompatible implementations, I
would side with the one that didn't break any rules, at least with
regard to whether it should be called Ethernet or 802.3.

I am also against the philosophy of "as long as it's less than a slot
time you can do anything you feel like".  In a large network where
personnel come and go, it is very likely that a shortcut taken in one
area will be forgotten and badly burn someone (many people?) somewhere
down the line.  It's all very nice to document what you did but I
think there was a reason DIX came up with the configuration rules in
the first place.  Otherwise, they could just have said "here, don't
violate the slot time and have fun". But they knew it would be much
less error prone to establish some simple, conservative configuration
rules. It's very easy to poke holes in them. They were designed to be
conservative. And I think in a network where downtime affects the
entire computing community, erring on the side of too much safety
margin is worth it.

It's true that standards retard the advancement of the state of the
art.  As a system engineer, I am more concerned with connectivity than
an occasional local optimization, particularly if it means the whole
network is affected or threatened. This is even more true with the
advent of devices like the LAN Bridge 100 which allow full Ethernet
speed over extended geographic distances. There's no longer any excuse
to cheat the specs to get an extra 500 meters or whatever.

	Phil Ngai
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Oct 86 10:14:21 EDT
From:      jqj@gvax.cs.cornell.edu (J Q Johnson)
To:        arpa.tcp-ip
Subject:   Re: Congestion in the Arpanet
Has anyone done any modelling of the likely effect of the new NSF sites
and of NSFnet on ARPAnet traffic/performance?  Offhand, I would expect
that the changes (supercomputers with scientists all over the country
using telnet or tn3270 to get to them by ARPAnet, many more
NSF-supported hosts, and a new alternative backbone) are likely to have
massive effects on ARPAnet traffic patterns.  It would be nice to know
that someone had given some thought before the fact to the potential
effects!

Similarly, has anyone modelled the effect of widearea and wideband
regional nets such as the planned NY-wide 1Mbit network (NYSERNET)?
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Oct-86 11:13:42 EDT
From:      olson@TCGOULD.TN.CORNELL.EDU (olson)
To:        mod.protocols.tcp-ip
Subject:   Re: Peace fullness.

In article <8609280050.AA11782@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes:
>
>
>   Speeking as the president of one of those companies out there trying
>to make a living by selling TCP/IP code for PC's ...
>
>   I ask you, what would you do if you wanted to sell such a product.
>(Remember were a very small company)
>
>              - Carl Beame,
>                President
>                Beame & Whiteside Software Ltd.
>                259 Fiddler's Green Rd.
>                Ancaster, Ontario, Canada.

I'd sell it for a LOW price if at all possible.   You see i'm not going
to get tcp/ip for the pc's around my department at $1000 a shot or even
$500 hundred a shot.  I'd rather go to the campus computing people and
ask them to do the campus a favor and write something.  At ~ $100 I might
consider a commercial product.

But (I hear you say) I might as well give it away.  Well,  If it is good
you will probably sell a lot of them at the lower price.  Also you can
make money off of service.  (not fixing broken software)  Things like
helping a group figure out what they need, hardware and software.
That is a service you can charge for.

But (I hear you say)  We are small, we can't serve all our customers that
way.  Don't try.  Let other service groups grow up to help people network
(hopefully your software will be good enough for them to recomend)  You can
probably make a living off the people in your area by this sort of service
as well as get ideas for new products from the problems you solve for them.
If you write up very good documents on how to deal with these problems
you could sell them (text book level pricing) and if you really have
it together and can make your ideas clear and correct you can set up
a service franchise.  (Hello, you have our software, you are in L.A.
what part?  Okay, lets see, we have a service franchise at ... Why don't
talk to them first as they will be able to devote more time to your problem.
If you have trouble with them please call back.)  The franchizee will report
to you all problems they encounter with your software, and you will support
them with solutions.  You set standard for the franchice and in return
for being certified they pay you money.  This way you get all the feed back
you would if all your customers called you directly without the problems
of providing support once the problem has been solved.
(Damn, there I go again, giving away my best ideas.  But can you see
it "Hey Ma, Dad, I need a job should I try for a fast food joint or
a fast code joint." (so give me credit for the idea))

This way you can make a living with out having to become a corporate monster.

Todd Olson

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Oct-86 02:22:17 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   telnet synch

Almost all of our terminals are now connected to terminal servers
running telnet, instead of directly to computers.  I am getting tired
of typing ^O or ^C and having many screens full of data come out.  The
obvious fix is to implement the Telnet synch option.  I have done so,
more or less, and the improvement is quite welcome.  However the
description in RFC 854 leaves me feeling unsure of whether I have done
things right.  My interpretation of the spec is that when the host
machine wants to clear its output buffer, it should send IAC DM, with
the urgent pointer set to point to the DM.  

1) Am I correct that the only thing to be sent is IAC, DM?  The
description of synch makes it sound like two separate things are sent:
one out of band and the other in the normal data stream.  After
reading the description of urgent data about 5 times, I have finally
concluded that this the wrong conception of how urgent data works, and
that in fact only the IAC, DM is sent.

2) I find the whole concept of urgent data slightly odd.  Both the
telnet spec and the Unix implementation imply that urgent is some sort
of out of band data, that manages to arrive out of order, going ahead
of any normal data.  It looks to me like this isn't quite the case.
Rather there is a bit that says, "go into urgent mode".  It seems like
nobody really cares exactly when (i.e. at which byte) you go into
urgent mode.  Then there is a pointer that tells you the end of the
urgent data, at which point you go out of urgent mode.  4.2 seems to
have a different view of the world.  They pull the last byte of urgent
data out of the normal byte stream and call it out of band data.  It's
not clear whether this is quite what TCP had in mind.

3) The telnet spec further confuses things by saying that DM should be
transmitted as the only octet in an urgent message.  The problem is
that this seems to ignore the necessity for an IAC.

Anyway, from all of this, I conclude that synch should be implemented
as follows: When I type a ^O, put out an IAC, DM, and set the urgent
pointer so that the DM is the last byte of urgent data (the only byte
as far as Unix is concerned).  The way 4.2 works (at least on the
Pyramid), the moment I set the urgent pointer, all packets get the
urgent flag set until the point where the DM has been sent.  This
seems to be right.

What makes me suspicious of this is the 4.2 telnet seems to get
confused by it.  Telnet doesn't set up for the URGENT signal.  So the
final urgent byte, the DM, is simply removed from the input stream by
the kernel.  The result is mildly odd.  When I type ^O, the host ends
up echoing ^O back at me.  So the last few bytes of the data stream
are IAC DM <URGENT PTR> ^ O.  Since the DM is pulled out by the kernel,
Unix sees IAC ^, which is of course a bogus telnet command, and prints
only the O.  If I understand what is going on properly, what I am
sending is right, and it is the combination of 4.2 and 4.2 telnet that
is wrong.  Has anybody followed me to this point?  Do I seem to be
making sense?

Fortunately, our two kinds of terminal servers (Bridge CS/100's and
Cisco ASM's) both seem to do the right thing.  It's *so* nice to have
^C and ^O work again.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 1986 1230-PDT (Monday)
From:      Bill Croft <croft@safe.stanford.edu>
To:        tcp-ip@sri-nic.ARPA
Cc:        ehrlich%psuvax1.bitnet@WISCVM.WISC.EDU
Subject:   re: BOOTP daemon for BSD 4.x
Client and server implementations of BOOTP (Bootstrap Protocol, RFC 951)
are available via anonymous ftp from host safe.stanford.edu, in the files:

	pub/bootp.client.shar
	pub/bootp.server.shar

Both implementations are in C, the server code for 4.2 BSD, the
client code resides in PROM in our campus gateways/tips (multibus
68000 systems).  The client autoconfigures for a number of different
ethernet board manufacturers (3COM, Interlan, ...).

The BOOTP protocol is defined such that clients can boot themselves
even when: (1) the client is on an ether segment without a boot server
host.  (2) the client doesnt yet know its own IP address.

	--Bill Croft, Stanford Univ.



------- End of Forwarded Message
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Oct-86 15:30:00 EDT
From:      croft@safe.stanford.edu (Bill Croft)
To:        mod.protocols.tcp-ip
Subject:   re: BOOTP daemon for BSD 4.x

Client and server implementations of BOOTP (Bootstrap Protocol, RFC 951)
are available via anonymous ftp from host safe.stanford.edu, in the files:

	pub/bootp.client.shar
	pub/bootp.server.shar

Both implementations are in C, the server code for 4.2 BSD, the
client code resides in PROM in our campus gateways/tips (multibus
68000 systems).  The client autoconfigures for a number of different
ethernet board manufacturers (3COM, Interlan, ...).

The BOOTP protocol is defined such that clients can boot themselves
even when: (1) the client is on an ether segment without a boot server
host.  (2) the client doesnt yet know its own IP address.

	--Bill Croft, Stanford Univ.



------- End of Forwarded Message

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Oct 86 08:40 PDT
From:      Todd Booth 213-825-1933 <CSDCTGB@UCLA-CCN.ARPA>
To:        Submit to TCP/IP <tcp-ip@sri-nic.arpa>
Cc:        Vivian Neou - Coordinator of TCP-IP <vivian@sri-nic.arpa>
Subject:   Protocol of Submissions
It's time to settle this "commercial vs university" issue.

> From: mckee@mitre.ARPA
>
> I object to moving the discussion of commercial vs university
> requirements off of tcp-ip.

Then you may wish to send a message to the coordinator of the Digest
who intended this digest for the following purpose:

"To announce new and expanded services in a timely manner.",

according to their advertising in SRI-NIC Netinfo:Interest-Groups-2.txt

> The tcp-ip community needs to at least understand, and hopefully
> accomodate, the contending views of public and private
> organizations.

You may be right, but if the main-stream of the group doesn't
want to hear about, so be it.  The digest wasn't intended to
act as a big brother.

If you are so interested in this topic, you should be *happy*
to start your own digest.   (I've set up PC-Token-Ring Digest
and can give you a hand.)  You may get some interest on your
topic regarding products other than tcp-ip.

> The discussion should continue on tcp-ip.
> H. Craig McKee

The next message on "commercial vs university" should be from a
volunteer to help with the digest.  (If anyone really cares so
much that they would help.)

Of course, the TCP-IP coordinator can overrule me if I have mis-
interpreted the protocol discussion.

-todd / UCLA Data Comm

ps. CASE CLOSED

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Oct-86 08:57:08 EDT
From:      mckenzie@J.BBN.COM (Alex McKenzie)
To:        mod.protocols.tcp-ip
Subject:   Modelling of NSF sites on ARPANET

The DDN Program Management Office (PMO) is responsible for management decisions
regarding the ARPANET.  It is my understanding that the DDN PMO assigned the
task of analyzing the performance of the ARPANET with the addition of NSF sites
to the Defense Communications Engineering Center (DCEC).  It is my
understanding that DCEC uses the same network analysis tools and models which
were used to manage the ARPANET configuration at the time of its rapid growth
in the early to mid 70s.  The statements above are second-hand or farther - I
do not have first-hand knowledge, except that I know BBN was not assigned this
analysis task.  Perhaps someone from the DDN PMO can tell us all more.

Alex McKenzie
BBN Labs

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Oct 86 8:57:08 EDT
From:      Alex McKenzie <mckenzie@j.bbn.com>
To:        J Q Johnson <jqj@gvax.cs.cornell.edu>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Modelling of NSF sites on ARPANET
The DDN Program Management Office (PMO) is responsible for management decisions
regarding the ARPANET.  It is my understanding that the DDN PMO assigned the
task of analyzing the performance of the ARPANET with the addition of NSF sites
to the Defense Communications Engineering Center (DCEC).  It is my
understanding that DCEC uses the same network analysis tools and models which
were used to manage the ARPANET configuration at the time of its rapid growth
in the early to mid 70s.  The statements above are second-hand or farther - I
do not have first-hand knowledge, except that I know BBN was not assigned this
analysis task.  Perhaps someone from the DDN PMO can tell us all more.

Alex McKenzie
BBN Labs

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Oct-86 09:11:00 EDT
From:      Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM (Benson I. Margulies)
To:        mod.protocols.tcp-ip
Subject:   Re: Peace fullness.


    Date: Sun, 5 Oct 86 11:13:42 EDT
    From: olson@tcgould.tn.cornell.edu (olson)

    In article <8609280050.AA11782@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes:
    >
    >
    >   Speeking as the president of one of those companies out there trying
    >to make a living by selling TCP/IP code for PC's ...
    >
    >   I ask you, what would you do if you wanted to sell such a product.
    >(Remember were a very small company)
    >
    >              - Carl Beame,
    >                President
    >                Beame & Whiteside Software Ltd.
    >                259 Fiddler's Green Rd.
    >                Ancaster, Ontario, Canada.


In the same spirit of free-enterprise that drives Mr. Beame, I don't see
why we should all be giving him @i(free) advice.  Other people have made
quite comfortable livings commercializing things that were born in
Universities (um, for example, Symbolics), why is he any different?  If
he is unconvinced of the pofitability of PC IP/TCP, let him go do
something else.  Someone else will turn up with a different idea.  
If he's trying to imply that @i(no one) will ever turn out a commercial
product as long as university freebies exist, he's just plain wrong. Go
ask wollagong.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Oct-86 10:58:23 EDT
From:      markl@jhereg.lcs.mit.edu
To:        mod.protocols.tcp-ip
Subject:   Re: IP source routing questions


>
>     host A           gate B           gate C           host D
>    +------+         +------+         +------+         +------+
>    |      |         |      |         |      |         |      |
>    |    A1|-------->|B1  B2|-------->|C2  C3|-------->|D3    |
>    |      |  net 1  |      |  net 2  |      |  net 3  |      |
>    +------+         +------+         +------+         +------+
>
>where A1, B1, B2, etc. are IP addresses.  I think that the upper layer
>protocol in host A should pass the following IP header values to the
>IP layer:
>             source:A1  destination:B1  route:B1,C2,D3  offset:4


I know how you feel about the source routing spec [I had to implement
it for our NETBLT IP protocol -- a bit of a headache...].

Indeed, the offset at start is 4, however the route is not quite as
you specify it.  The source host is A1 and the destination host B1;
the initial route is C2,D3.  

on host A:   source:A1  destination:B1  route:C2,D3  offset:4

at gate B:   source:A1  destination:C2  route:B2,D3  offset:8

at gate C:   source:A1  destination:D3  route:B2,C3  offset:12

The source host's IP address never changes; the only addresses that
change are the intermediate addresses and the destination address.

The idea behind replacing the source route addresses with the recorded
route addresses is that the IP packet doesn't change size when it
passes through a gateway.  It also preovides the destination host with
an (albeit reversed) route back to the source host.  The offset pointer
tells each gateway where to insert its recorded route address.  When
the packet arrives, the destination host flips the route around,
removes the first hop on the route and makes it the destination, and
adds the final destination host as the last hop on the route.  It also
resets the offset value to 4.

Host D3 goes through the following machinations before sending a
packet back to A1:

source route flipped, offset set to 4:

	     source:D3   destination:<NULL>  route:C3,B2  offset:4

first hop removed and made destination:

	     source:D3   destination:C3      route:B2     offset:4

final destination added to route:

	     source:D3   destination:C3      route:B2,A1  offset:4

This is the packet that is sent out.


Hope this was of some help (and that I got it right :-)


				MarkL

Internet: markl@jhereg.lcs.mit.edu

MIT Laboratory for Computer Science
Distributed Systems Group

----------

"...the MGA 1600 Mk-II: Precision sports motoring in the MG racing
tradition..."

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Oct-86 11:35:47 EDT
From:      mckee@MITRE.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Peace fullness.


I object to moving the discussion of commercial vs university
requirements off of tcp-ip.  The tcp-ip community needs to at least
understand, and hopefully accomodate, the contending views of public
and private organizations.  The discussion should continue on tcp-ip.

H. Craig McKee

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Oct-86 11:40:00 EDT
From:      CSDCTGB@UCLA-CCN.ARPA (Todd Booth 213-825-1933)
To:        mod.protocols.tcp-ip
Subject:   Protocol of Submissions

It's time to settle this "commercial vs university" issue.

> From: mckee@mitre.ARPA
>
> I object to moving the discussion of commercial vs university
> requirements off of tcp-ip.

Then you may wish to send a message to the coordinator of the Digest
who intended this digest for the following purpose:

"To announce new and expanded services in a timely manner.",

according to their advertising in SRI-NIC Netinfo:Interest-Groups-2.txt

> The tcp-ip community needs to at least understand, and hopefully
> accomodate, the contending views of public and private
> organizations.

You may be right, but if the main-stream of the group doesn't
want to hear about, so be it.  The digest wasn't intended to
act as a big brother.

If you are so interested in this topic, you should be *happy*
to start your own digest.   (I've set up PC-Token-Ring Digest
and can give you a hand.)  You may get some interest on your
topic regarding products other than tcp-ip.

> The discussion should continue on tcp-ip.
> H. Craig McKee

The next message on "commercial vs university" should be from a
volunteer to help with the digest.  (If anyone really cares so
much that they would help.)

Of course, the TCP-IP coordinator can overrule me if I have mis-
interpreted the protocol discussion.

-todd / UCLA Data Comm

ps. CASE CLOSED

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Oct-86 12:39:55 EDT
From:      brescia@CCV.BBN.COM (Mike Brescia)
To:        mod.protocols.tcp-ip
Subject:   Re: IP source routing questions

Steve,

The following points are important:
- the IP source field remains constant, so that the higher level protocol can
  ignore the recorded route
- the IP destination field reflects the current goal, and not the ultimate
  destination, until the source route has been consumed
- the offset includes the first 3 bytes and is zero-based.  "... the smallest
  legal value for the pointer is 4."

          host A           gate B           gate C           host D
         +------+         +------+         +------+         +------+
         |      |         |      |         |      |         |      |
         |    A1|-------->|B1  B2|-------->|C2  C3|-------->|D3    |
         |      |  net 1  |      |  net 2  |      |  net 3  |      |
         +------+         +------+         +------+         +------+

    (..host..)    source:A1  destination:B1  route:B1,C2,D3  offset:4
     on net 1:    source:A1  destination:B1  route:A1,C2,D3  offset:8
     on net 2:    source:A1  destination:C2  route:A1,B2,D3  offset:12
     on net 3:    source:A1  destination:D3  route:A1,B2,C3  offset:16

What you show is the way TOPS20 has implemented it, where host A has put a
record of its outgoing interface into the packet.  The unix implementations
do not do this, and the source route option only has 2 hops.

Here is an example of unix flavor source routed packet, with an octal dump of
the packet on the way out of teh source host, and another on receipt at the
destination (the same host in this case).  Note also the extra pad (1) option.

A1=10.2.0.82
B1=10.2.0.5     B2=128.89.0.5
		C2=128.89.0.4   C3=10.3.0.82
				D3=10.2.0.82
Outgoing packet:
   110      0      0     54      0      0    100      0     31     24 
   263     53     12      2      0    122     12      2      0      5 
     1    203     13      4    200    131      0      4     12      2 
     0    122      1    226      0      0      0      0      0    305 
   147    244    226      0 

Incoming packet:
   110      0      0     54      0      0    100      0     27     24 
   264    324     12      2      0    122     12      2      0    122 
     1    203     13     14    200    131      0      5     12      3 
     0    122      1    226      0      0      0      0      0    305 
   147    244    226      0 

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      07 Oct 86 12:39:55 EDT (Tue)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        Steve Deering <deering@pescadero.stanford.edu>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: IP source routing questions
Steve,

The following points are important:
- the IP source field remains constant, so that the higher level protocol can
  ignore the recorded route
- the IP destination field reflects the current goal, and not the ultimate
  destination, until the source route has been consumed
- the offset includes the first 3 bytes and is zero-based.  "... the smallest
  legal value for the pointer is 4."

          host A           gate B           gate C           host D
         +------+         +------+         +------+         +------+
         |      |         |      |         |      |         |      |
         |    A1|-------->|B1  B2|-------->|C2  C3|-------->|D3    |
         |      |  net 1  |      |  net 2  |      |  net 3  |      |
         +------+         +------+         +------+         +------+

    (..host..)    source:A1  destination:B1  route:B1,C2,D3  offset:4
     on net 1:    source:A1  destination:B1  route:A1,C2,D3  offset:8
     on net 2:    source:A1  destination:C2  route:A1,B2,D3  offset:12
     on net 3:    source:A1  destination:D3  route:A1,B2,C3  offset:16

What you show is the way TOPS20 has implemented it, where host A has put a
record of its outgoing interface into the packet.  The unix implementations
do not do this, and the source route option only has 2 hops.

Here is an example of unix flavor source routed packet, with an octal dump of
the packet on the way out of teh source host, and another on receipt at the
destination (the same host in this case).  Note also the extra pad (1) option.

A1=10.2.0.82
B1=10.2.0.5     B2=128.89.0.5
		C2=128.89.0.4   C3=10.3.0.82
				D3=10.2.0.82
Outgoing packet:
   110      0      0     54      0      0    100      0     31     24 
   263     53     12      2      0    122     12      2      0      5 
     1    203     13      4    200    131      0      4     12      2 
     0    122      1    226      0      0      0      0      0    305 
   147    244    226      0 

Incoming packet:
   110      0      0     54      0      0    100      0     27     24 
   264    324     12      2      0    122     12      2      0    122 
     1    203     13     14    200    131      0      5     12      3 
     0    122      1    226      0      0      0      0      0    305 
   147    244    226      0 
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Oct-86 00:56:00 EDT
From:      phil@amdcad.UUCP
To:        mod.protocols.tcp-ip
Subject:   testing

Recently, I became aware that by following "proper" procedures for
posting into ARPAnet mailing lists, my articles were processed in such
a way as to never make it into the USENET side of the world. It
appears that these problems will be with us until the release and
installation of the long awaited 2.11 aka 2.10.3 netnews.

In the meantime I am going to cheat and bypass the "proper" procedure.

I do not know if this method will get into the ARPAnet. If it does
not, I will have to send my articles out twice. If you are receiving
this note via an ARPAnet mailing list, could you please let me know so
I can avoid duplications? Thanks.

-- 
 DIP stands for DECnet-DOS Installation Procedure.

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed 8 Oct 86 07:13:37-EDT
From:      Dennis G. Perry <PERRY@VAX.DARPA.MIL>
To:        tcp-ip@SRI-NIC.ARPA, steve@BRL.ARPA
Cc:        perry@VAX.DARPA.MIL
Subject:   [Jeff Mayersohn <mayersoh@cc5.bbn.com>: more on arpanet]
The latest in the ongoing saga, or "How to train a neglected child to
behave properly"

dennis
                ---------------

Received: from CC5.BBN.COM by vax.darpa.mil (4.12/4.7)
	id AA29722; Wed, 8 Oct 86 01:45:47 edt
Message-Id: <8610080545.AA29722@vax.darpa.mil>
To: prishivalko@ddn1.ARPA, grindle@ddn1.ARPA, leonard@ddn1.ARPA,
        arpanetmgr@ddn1.ARPA
To: perry@vax.darpa.mil, blumenthal@cc5.bbn.com, hinden@cc5.bbn.com,
        mckenzie@cc5.bbn.com, pogran@cc5.bbn.com
To: jburke@cc5.bbn.com, bartlett@cc5.bbn.com
Cc: mayersoh@cc5.bbn.com, jwiggins@cc5.bbn.com, cgreenleaf@cc5.bbn.com,
        rpyle@cc5.bbn.com, fserr@cc5.bbn.com
Subject: more on arpanet
Date: 08 Oct 86 01:34:20 EDT (Wed)
From: Jeff Mayersohn <mayersoh@cc5.bbn.com>

I wanted to bring everyone up to date on the progress of our
investigation into Arpanet congestion. 

There has been one major "discovery" made during the last week.
Apparently, in the middle of August, the line between the two USC
packet switches, which used to be a stub, was placed into the main
cross-country path.  The problem is that this line, which connects two
endpoints on the USC campus, is apparently running at 19.2 kbps.  This
change to the network topology is like closing a lane on Storrow Drive
during rush hour.  It congests both the main artery and the roads
which feed it.  This is undoubtedly a major contributor to the
cross-country congestion that we are seeing; the line should have its
capacity increased at once.  This piece of information has been
communicated by Bob Steele, here at BBNCC, to the Arpanet manager at
DCA. 

In the past few weeks, it has been observed that some of the links on
the major cross-country paths have been bouncing up and down.  We
believe this is due to a known problem in the microcode; the Arpanet
has not been running the most current microcode release.  The newer
release is in the process of being installed.  TAC 113, which contains
several efficiencies, is also in the process of being installed.  Jeff
Burke tells me that these upgrades will be finished within the week.

Tracy Mallory and Bob Hinden tell me that a new release of the
mailbridge was installed in the network and changes have been made to
the routing tables in the Butterfly gateways which cause some traffic
to favor the Wideband Network over the Arpanet. 

John Wiggins and Clive Greenleaf have made a number of measurements on
the Arpanet and have made a number of parameter changes in the packet
switch software.  First, it was observed that routing updates were
being generated at very close to the maximum frequency, a sure sign
that routing is thrashing in its attempt to deal with congestion.
Changes were made to line parameters to stabilize routing by reporting
more or less equivalent delays on the three cross-country paths.  It
was expected that this would reduce the pointless movement of traffic
from one trunk to another.  In addition, it was observed that there
were end-to-end resource shortages in a number of packet switches.
John modified a parameter which reduces the amount of time that a
source packet switch can hold on to resources that it has reserved in
a destination packet switch.  The hope is that this would alleviate
some of the contention for end-to-end resources.

The changes described in the last paragraph and (I believe) the
installation of the new mailbridge release were made on October 2.
Measurements made by Wiggins and Greenleaf on October 3 suggest that
the changes had a positive effect.  Traffic in the network increased
by about 30% (from October 2 to October 3) during the peak period and
round trip delays were halved.  The major symptoms of congestion 
persisted, however.

There are two other observations to be made.  There appears to have
been a change in some of the characteristics of the network traffic
recently.  In particular, we have observed an increase in the distance
between communicating hosts from an average of 2.75 in June to 3.54 in
October.  This is worth looking into. 

Second, some of the mail on TCP-IP questions why cross-country
subnetwork congestion should affect traffic between, say, Stanford and
SRI.  Clive Greenleaf has looked into this and has produced the
following explanation.  In order to send a message between a pair of
packet switches, resources are used in both the source and
destination.  What is happening is that the long delays across the
network are causing these resources to be held for long periods of
time.  The fact that these resources are so occupied is affecting all
other traffic to and from a given switch, even if that traffic is to
or from adjacent switches, or local to the switch.  The
Stanford IMP, which seems to send traffic to a large number of remote
destinations, and the SRI IMP appear to be major victims of this
phenomenon. 

Anyway, here's where we stand: 

1) The USC line should be upgraded asap. 

2) The microcode release which should eliminate the flapping of key
lines is being installed. 

3) The TAC release which should reduce TCP retransmissions and network
overhead is being installed. 

4) We are making store-and-forward statistics measurements to identify
all subnetwork bottlenecks. 

5) We will produce a complete host traffic matrix in order to
determine how the network traffic has changed and to determine whether
any hosts are exhibiting antisocial behavior. 

6) The topological changes recommended in my previous message should
be made.  Recall that the network was showing symptoms of congestion
in June, before the USC line was thrown into the cross-country path. 

7) We intend to produce a new set of recommended assignments of hosts
to mailbridges and may recommend the addition of mailbridges when this
analysis is complete.
-------
-------
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1986 12:19-EDT
From:      CLYNN@A.BBN.COM
To:        deering@PESCADERO.STANFORD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP source routing questions
Steve,
        The source routing that you have described is much better than
that in the second message (from MarkL).  The latter ignores the fact
that a host (A) may be multiply homed, either to a single net or to
multiple nets, and thus may not provide the destination host (D) with
sufficient information to be able to return a datagram to the soure
host (A) by inverting the route (as described in the second message).
In fact it is most likely to fail just when it is most needed -- when
one of A's interfaces/network+gateway has failed.

        For example, consider the case where A has two interfaces, A1
and A2, to your net 1 and net 2.  A TCP connection between A and D
should use A2 as the ADDRESS representation for A's NAME since it is
one network closer to D.  Thus the source would be A2 and the
destination D3.  If A's interface to net 2 should fail, the failure
should be reported to the higher layers, e.g., IP and the IP routing
algorithm would select the other interface, A1, to send the packet.
This won't "work" since the return packets have A2 as the destination
and that path is non-functioning.  This is where a "robust" host
implementation would like to use a source route to specify that
(return) packets to A2 should be source routed via A1.  The
implementation that you describe can do this because the record route
option has the IP address of the host interface which was used to send
the packet; the other implementation will fail because it does not.

        Note that in the above it is assumed that a system receiving a
source routed packet will invert the route and use it for outgoing
packets.  Note also that it is not something that would "properly" be
done at the IP level, but at a higher level such as TCP or UPD,
automatically unless a higher level protocol/application has specified
something to the contrary.  This "robustness" requirement is not
described anywhere in the IP/TCP/xxx protocol specifications.

Charlie
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Oct-86 12:29:37 EDT
From:      ddp@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        mod.protocols.tcp-ip
Subject:   IP on 802.5


It's been a while since the last message about this, so I thought I'd bring
it back up.  Last we heard, John posted his proposed standard using a new
field in 802.2 called the SNAP.  Does anyone know if anything has happened
towards getting official numbers for this yet?  I see more and more
tokenring's being deployed with various bogus schemes while this issue
remains unresolved.

Drew

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Oct-86 14:36:27 EDT
From:      ron@BRL.ARPA (Ron Natalie)
To:        mod.protocols.tcp-ip
Subject:   Re:  Peace fullness.

Wollengong is a commercialization of University research.  Their code
is all based on the original Berkeley implementations.  Not to say that
they didn't do a lot of work to get it to run in hostile environments
like VMS and System V.

-Ron

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Oct-86 05:42:42 EDT
From:      bjp@MITRE-BEDFORD.ARPA
To:        mod.protocols.tcp-ip
Subject:   New Version of the Ulana Specifications


This noice is to announce that a new version of the ULANA Specifications has
been released and now is available at the ulana ftp site.

		address:	mitre-b-ulana.arpa
		user:		guest
		password:	anonymous
		pathname:	/usr/mitre/guest/ulana.specs

Any comments about the specifications should be mailed to:

		ulana@mitre-bedford.arpa

General correspondence should be mailed to:

		bjp@mitre-bedford.arpa

						bj Pease

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Oct-86 11:38:37 EDT
From:      minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU
To:        mod.protocols.tcp-ip
Subject:   Re: telnet synch

Charles,

    1) Am I correct that the only thing to be sent is IAC, DM?  The
    description of synch makes it sound like two separate things are sent:
    one out of band and the other in the normal data stream.  After
    reading the description of urgent data about 5 times, I have finally
    concluded that this the wrong conception of how urgent data works, and
    that in fact only the IAC, DM is sent.

Yes, you only send IAC, DM.  You should note, by the way, that BSD systems
have the TCP RFC concept of what the urgent pointer is (one byte PAST the
last byte of urgent data), when the "official protocols RFC" (and the MIL-STD)
have changed the definition to point at the LAST byte of urgent data (a
rather strange definition, given what TCP ack numbers are).

    2) I find the whole concept of urgent data slightly odd.  Both the
    telnet spec and the Unix implementation imply that urgent is some sort
    of out of band data, that manages to arrive out of order, going ahead
    of any normal data.  It looks to me like this isn't quite the case.
    Rather there is a bit that says, "go into urgent mode".  It seems like
    nobody really cares exactly when (i.e. at which byte) you go into
    urgent mode.  Then there is a pointer that tells you the end of the
    urgent data, at which point you go out of urgent mode.  4.2 seems to
    have a different view of the world.  They pull the last byte of urgent
    data out of the normal byte stream and call it out of band data.  It's
    not clear whether this is quite what TCP had in mind.

Urgent IS out of band data; the only thing is that the out of band data
is only 1 bit worth: "there is an urgent condition present in the
data flow".  BSD took the "out of band" approach, and actually tried
to identify an out-of-band BYTE.  This is unreliable, and 4.3 allows
a socket option (SO_OOBINLINE) to remove this concept (for incoming
data).

    3) The telnet spec further confuses things by saying that DM should be
    transmitted as the only octet in an urgent message.  The problem is
    that this seems to ignore the necessity for an IAC.

The reason for this is, probably, the confusion about which byte is
the urgent byte.  What they are saying is "transmit IAC normally,
then transmit DM urgently, then transmit whatever else you want normally"
(ie: two or three seperate calls to "tcp_send").

    Anyway, from all of this, I conclude that synch should be implemented
    as follows: When I type a ^O, put out an IAC, DM, and set the urgent
    pointer so that the DM is the last byte of urgent data (the only byte
    as far as Unix is concerned).  The way 4.2 works (at least on the
    Pyramid), the moment I set the urgent pointer, all packets get the
    urgent flag set until the point where the DM has been sent.  This
    seems to be right.

Because of the confusion about which byte is urgent, because of BSD
being one number too high, because of the TELNET spec's algorithm for
when to LEAVE synch mode, the thing to do is to send the IAC as
urgent (MSG_OOB?), then the DM as normal.  Thus, the receiver will
either see the urgent mode go away after receiving the IAC, or
after the DM (the former if the receiver is a BSD system, the latter
if the receiver is some other, MIL-STD conforming, system).

    What makes me suspicious of this is the 4.2 telnet seems to get
    confused by it.  Telnet doesn't set up for the URGENT signal.  So the
    final urgent byte, the DM, is simply removed from the input stream by
    the kernel.  The result is mildly odd.  When I type ^O, the host ends
    up echoing ^O back at me.  So the last few bytes of the data stream
    are IAC DM <URGENT PTR> ^ O.  Since the DM is pulled out by the kernel,
    Unix sees IAC ^, which is of course a bogus telnet command, and prints
    only the O.  If I understand what is going on properly, what I am
    sending is right, and it is the combination of 4.2 and 4.2 telnet that
    is wrong.  Has anybody followed me to this point?  Do I seem to be
    making sense?

This is fixed in the 4.3 server (and client).

    Fortunately, our two kinds of terminal servers (Bridge CS/100's and
    Cisco ASM's) both seem to do the right thing.  It's *so* nice to have
    ^C and ^O work again.

Summary:  look in the 4.3 telnet server and client code; implement
SO_OOBINLINE in your kernels.

Greg Minshall

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Oct-86 11:39:47 EDT
From:      tcp-ip-RELAY@SRI-NIC.ARPA (William Morgart)
To:        mod.protocols.tcp-ip
Subject:   IP source routing questions


	After reading the previous messages on IP routing options I thought
I'd mention a few problems with those messages. All of the problems
are caused by the differences between RFC791, The DARPA Internet Protocol
Specification, and MILSTD-1777, The DoD Military Standard Internet Protocol.

	The earlier messages stated that the destnation address
in the IP header is changed at intermedate gateways that are in the source
route list. This is only true if the IPs are implemented according to the RFC.
If the IP was implemented following the MILSTD, it will not change the
header. This is a little gotcha that must be watched since an implementation
meant for the DoD world of MILNET will be required to meet
the MILSTD and not the RFC.

	Another gotcha also relating to options processing is what
options are copied on fragmentation. In the RFC the
"Loose Source and Record Route" option is specified as being copied while
in the MILSTD it isn't copied. Even the MILSTD is confused on this point
since it defines the most significant bit of the option to be the copy flag
and the option type for LSRR is 0131 (octal) though the text in the MILSTD
specifies that LSRR isn't copied.

	Next, the security option as specified in both the RFC and the
MILSTD has been superseded by a new security option developed by the 
IPSO Working Group in early 1985. A document describing the new option
should be available for DCA or DDN.

	Finally, a comment for thought: since DoD via DARPA is paying for
the ARPANET and MILNET plus requiring that MILNET use the MILSTD verison
of IP, the ARPANET side of the world should think about using
the MILSTD version also. If this doesn't happen the two sides won't
be able to interoperate. 

Bill Morgart
bmorgart@mitre-gateway.arpa
Phone: (703) 883-6554

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 1986 17:01-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP source routing questions
*sigh*  Speaking  as  one  of  those people who gets to fight the
protocol battles at the DDN PMO (ever hear of Capt Don  Quixote),
the MIL STDs are suppoosed to mirror the RFC's.  The places where
they don't mirror the RFC's are errors and should be reported  as
such.   *sigh*  The  MIL STDs have a page at the back that can be
used to report these errors.  You don't even have to put a  stamp
on  them.   It  may take a while, but eventually revised MIL STDs
will be issued.  Until then, use both the MIL STDs and  the  RFCs
to implement and ask questions here if they differ.

Also,  I've  been  trying  to  find  time to issue the revised IP
Security Option as an RFC, but no luck.  I am making it available
for    anonymous    FTP    from    the   NIC   under   the   path
"PS:<STJOHNS>IPSO.TXT".  As far as the status of the  IPSO  goes,
it  has  been  sent  to the printers and should be available SOON
from Navy Pubs.  The version I am making available should be  the
same   as  the  one  available  from  Navy  Pubs  with  the  slim
possibility of minor changes.

Mike StJohns, tilter at windmills
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Oct-86 14:03:12 EDT
From:      mwm@cuuxb.UUCP
To:        mod.protocols.tcp-ip
Subject:   Netnews in your mailbox

In article <8609302105.AA05950@cbosgd.ATT.COM> mark@cbosgd.att.com (Mark Horton) writes:
>>My host spends
>>90% of it's time on the ARPAnet sending and receiving INFO-THIS, and INFO-THAT.
>>Also, I have multiple users receiving the same message from INFO-WHATEVER
>>as separate TCP connections to my host.
>
>If the ARPANET mailing lists do turn out to be the cause of the problem,
>I'd like to suggest a possible solution:  Netnews.
 ...
>The major problems with using netnews on the ARPA Internet have
>historically been
 ...
>(2) Many users prefer to keep their mail and news lumped together
>in their mailbox. 

Recent versions of the MH mail handler allow you to read news
with your mail program(s); most easily under 4.xBSD with 
symbolic links from your mail directory into news directory's.

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Oct-86 15:55:07 EDT
From:      brescia@CCV.BBN.COM (Mike Brescia)
To:        mod.protocols.tcp-ip
Subject:   Re: IP source routing questions

(from bmogart@mitre)
     All of the problems are caused by the differences between RFC791, The
     DARPA Internet Protocol Specification, and MILSTD-1777, The DoD Military
     Standard Internet Protocol.

My understanding of mil-std-1777 was that it recast the darpa IP spec in
mil-std terminology.  I thought that there was no intent to change the spec,
or cause disinteroperability.  I would be interested in hearing if anyone has
implemented the mil-std spec /in vacuo/ and expected that implementation to
talk to any existing host, or pass packets through any existing gateway.

Mike

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      09 Oct 86 15:55:07 EDT (Thu)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: IP source routing questions
(from bmogart@mitre)
     All of the problems are caused by the differences between RFC791, The
     DARPA Internet Protocol Specification, and MILSTD-1777, The DoD Military
     Standard Internet Protocol.

My understanding of mil-std-1777 was that it recast the darpa IP spec in
mil-std terminology.  I thought that there was no intent to change the spec,
or cause disinteroperability.  I would be interested in hearing if anyone has
implemented the mil-std spec /in vacuo/ and expected that implementation to
talk to any existing host, or pass packets through any existing gateway.

Mike
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Oct 86 19:45 PDT
From:      Provan@LLL-MFE.ARPA
To:        tcp-ip@sri-nic.arpa
Subject:   re: IP source routing questions

there is an errata sheet on the Milspec for IP which corrects exactly
these problems.  unfortunately, i don't remember where it is or even
whether it's been officially released.  since there are bugs in the
Milspec that appear to me to prevent actually implementing it, i
don't think there's too much worry about someone implementing it in
a vacuum.
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Oct-86 20:58:51 EDT
From:      swb@DEVVAX.TN.CORNELL.EDU (Scott Brim)
To:        mod.protocols.tcp-ip
Subject:   telnet synch


   Fortunately, our two kinds of terminal servers (Bridge CS/100's and
   Cisco ASM's) both seem to do the right thing.  It's *so* nice to have
   ^C and ^O work again.

Does anyone know if Encore Annexes [seem to] do the right thing?
							Scott

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Oct-86 22:45:00 EDT
From:      Provan@LLL-MFE.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: IP source routing questions


there is an errata sheet on the Milspec for IP which corrects exactly
these problems.  unfortunately, i don't remember where it is or even
whether it's been officially released.  since there are bugs in the
Milspec that appear to me to prevent actually implementing it, i
don't think there's too much worry about someone implementing it in
a vacuum.

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Oct-86 00:53:56 EDT
From:      OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen)
To:        mod.protocols.tcp-ip
Subject:   MIL-STD Problems


RFC's 963 and 964 by Sidhu list problems (errors?) in the MIL-STD specs
for IP and TCP.  Avaiable from you-know-where.

Ole
-------

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 1986 06:02-EDT
From:      CERF@A.ISI.EDU
To:        CLYNN@BBNA.ARPA
Cc:        deering@PESCADERO.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP source routing questions
Charlie,

For the case in point where a packet for a TCP connection is re-routed
to arrive at a host on a distinct interface from the one the connection
originally was formed upon, how would the TCP layer properly map to
the correct connection, considering that the apparent destination
address in the IP would have changed from A1 to A2 - or do you leave
the A1 in place to aid TCP demuxing but source route to A2 (a change
in the interpretation of the source routing function att the IP level,
I think).

Vint
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11-Oct-86 21:07:47 EDT
From:      dave@dlb.UUCP
To:        mod.protocols.tcp-ip
Subject:   Wanted: members for panel discussion on tcp-ip and sna

I'll be chairing a panel discussion at /usr/group's UNIFORUM in
Washington DC in January, 1987; topic is tcp-ip vs sna.
I'm looking for speakers who can attend the conference and speak
for 10-20 minutes.  The abstract for the panel session is:
	This session will compare Transmission Control Protocol / Internet
	Protocol (TCP/IP) and System Network Architecture (SNA) networking
	for the UNIX community -- specifically, basic capabilities of the
	two networks and common applications in commercial networks.
	It will also address the potential for (and value of) co-existence
	of the two protocols, gateways between them and advanced network
	capabilities, including PC-to-mainframe communications.
The session is scheduled for 22 Jan 87, 14:00 to 15:30 EST.
If you know of someone who might be interested in speaking, please have them
contact me as soon as possible.

--
Dave Buck	(408)972-2825	dave@dlb.BUCK.COM, {amdahl,sun}!dlb.UUCP!dave
D.L.Buck&Assoc.,Inc.	6920 Santa Teresa Blvd.		San Jose, Calif.95119

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1986 14:48:11 PDT
From:      POSTEL@B.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Source Routing


Hi.  I have a draft RFC on the IP Source Routing Option.  If you are
interested in reviewing it please copy it via FTP from "B.ISI.EDU".
The FTP pathname is "<INTERNET-NOTEBOOK>SRC-RTE.DRAFT".  The current
MIL-STD-1777 is wrong about some of the details of the IP Source Route
Options.

--jon.
-------
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1986 15:50:45 PDT
From:      POSTEL@B.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   RFCs & MIL-STDs

Hi.

It is the intention that the RFC specifications and the MIL-STD
specifications describe exactly the same protocols.  In principle, an
implementation based solely on the RFCs should interoperate with an
implementation based solely on the MIL-STDs.  In practice, every
implementer should make use of both the RFC documents and the MIL-STD
documents.  The notion that the RFCs apply to ARPANET, and the
MIL-STDs to MILNET is wrong.  If an implementer thinks there is a
difference in what is required between the RFCs and the MIL-STDs that
difference should be reported to DCA and the IAB and be resolved.

--jon.
-------
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1986 16:26:38 PDT
From:      POSTEL@B.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   IP on 802


Well, i haven't got an RFC out yet, but the procedure described in the
following memo should be used anyway.  There is a small and ever
decreasing possibility that the values of K1 and K2 may be different
than indicated below, so consider the possibility of having them
changable in your implementation.

In the mean time please go ahead and use this encapsulation format for
doing IP and ARP (and other things) on 802 nets,

                      using K1=170, and K2=0.

The IEEE likes to talk about bytes in little endian order so they say
K1 is 01010101.  The ARPA protocols have everything in big endian
order so that K1 becomes 10101010 binary or AA hex or 170 decimal.
This value is pretty definite.

The value of K2 is somewhat less certain, but no evidience to the
contrary has surfaced yet.

--jon.

*** begin ***

Date: 29 Aug 1986 19:27:12 PDT
From: POSTEL@B.ISI.EDU
Subject: How to IP & ARP on 802 Nets
To:   tcp-ip@SRI-NIC.ARPA

Hello. 

At an ad hoc special session on "IEEE 802 Networks and ARP" held
during the recent TCP Vendors Workshop, an approach to a consistent
way to sent DOD-IP datagrams and other IP related protocols on 802
networks was developed.

Due to some evolution of the IEEE 802.2 standards and the need to
provide for a standard way to do additional DOD-IP related protocols
(such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the
following new policy is being proposed, which will replace the current
policy (see page 26 of RFC-960 and RFC-948).

The proposal is for DDN and ARPA-Internet community to use IEEE
802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the
SNAP with an organization code indicating that the following 16 bits
specify the Ethertype code (where IP = 2048 (0800 hex), see page 27 of
RFC-960).


...--------+--------+--------+
 MAC Header|      Length     |                    802.{3/4/5} MAC Header
...--------+--------+--------+

+--------+--------+--------+
| Dsap=K1| Ssap=K1| control|                      802.2 SAP Header
+--------+--------+--------+

+--------+--------+---------+--------+--------+
|protocol id or org code =K2|    Ether Type   |   802.2  SNAP Header
+--------+--------+---------+--------+--------+

The values of K1 and K2 must be assigned by the IEEE.  We believe
there is already assigned a value of K1 that indicates that the
5-octet SNAP header follows.  We can use this value.  There may be a
value of K2 that is already assigned that indicates that the last two
octets of the SNAP header holds the EtherType.  If so we may be able
to use this value.  This remains to be explored.  The EtherTypes are
assigned by Xerox (as always).

The total length of the SAP Header and the SNAP header is 8-octets,
making the 802.2 protocol overhead come out on a nice octet boundary.

If we can not quickly resolve the issue of the values for K1 and K2,
we will push for the assignment of a sap value (a K1 value) to
indicate "IP related protocols" and do our own multiplexing (much like
that proposed above).

In any case, we will not create incompatible interpretations of
headers already in use on 802 networks.

***  end  ***
-------
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Oct-86 17:48:11 EDT
From:      POSTEL@B.ISI.EDU
To:        mod.protocols.tcp-ip
Subject:   Source Routing



Hi.  I have a draft RFC on the IP Source Routing Option.  If you are
interested in reviewing it please copy it via FTP from "B.ISI.EDU".
The FTP pathname is "<INTERNET-NOTEBOOK>SRC-RTE.DRAFT".  The current
MIL-STD-1777 is wrong about some of the details of the IP Source Route
Options.

--jon.
-------

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Oct-86 18:50:45 EDT
From:      POSTEL@B.ISI.EDU
To:        mod.protocols.tcp-ip
Subject:   RFCs & MIL-STDs


Hi.

It is the intention that the RFC specifications and the MIL-STD
specifications describe exactly the same protocols.  In principle, an
implementation based solely on the RFCs should interoperate with an
implementation based solely on the MIL-STDs.  In practice, every
implementer should make use of both the RFC documents and the MIL-STD
documents.  The notion that the RFCs apply to ARPANET, and the
MIL-STDs to MILNET is wrong.  If an implementer thinks there is a
difference in what is required between the RFCs and the MIL-STDs that
difference should be reported to DCA and the IAB and be resolved.

--jon.
-------

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Oct-86 19:26:38 EDT
From:      POSTEL@B.ISI.EDU
To:        mod.protocols.tcp-ip
Subject:   IP on 802



Well, i haven't got an RFC out yet, but the procedure described in the
following memo should be used anyway.  There is a small and ever
decreasing possibility that the values of K1 and K2 may be different
than indicated below, so consider the possibility of having them
changable in your implementation.

In the mean time please go ahead and use this encapsulation format for
doing IP and ARP (and other things) on 802 nets,

                      using K1=170, and K2=0.

The IEEE likes to talk about bytes in little endian order so they say
K1 is 01010101.  The ARPA protocols have everything in big endian
order so that K1 becomes 10101010 binary or AA hex or 170 decimal.
This value is pretty definite.

The value of K2 is somewhat less certain, but no evidience to the
contrary has surfaced yet.

--jon.

*** begin ***

Date: 29 Aug 1986 19:27:12 PDT
From: POSTEL@B.ISI.EDU
Subject: How to IP & ARP on 802 Nets
To:   tcp-ip@SRI-NIC.ARPA

Hello. 

At an ad hoc special session on "IEEE 802 Networks and ARP" held
during the recent TCP Vendors Workshop, an approach to a consistent
way to sent DOD-IP datagrams and other IP related protocols on 802
networks was developed.

Due to some evolution of the IEEE 802.2 standards and the need to
provide for a standard way to do additional DOD-IP related protocols
(such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the
following new policy is being proposed, which will replace the current
policy (see page 26 of RFC-960 and RFC-948).

The proposal is for DDN and ARPA-Internet community to use IEEE
802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the
SNAP with an organization code indicating that the following 16 bits
specify the Ethertype code (where IP = 2048 (0800 hex), see page 27 of
RFC-960).


...--------+--------+--------+
 MAC Header|      Length     |                    802.{3/4/5} MAC Header
...--------+--------+--------+

+--------+--------+--------+
| Dsap=K1| Ssap=K1| control|                      802.2 SAP Header
+--------+--------+--------+

+--------+--------+---------+--------+--------+
|protocol id or org code =K2|    Ether Type   |   802.2  SNAP Header
+--------+--------+---------+--------+--------+

The values of K1 and K2 must be assigned by the IEEE.  We believe
there is already assigned a value of K1 that indicates that the
5-octet SNAP header follows.  We can use this value.  There may be a
value of K2 that is already assigned that indicates that the last two
octets of the SNAP header holds the EtherType.  If so we may be able
to use this value.  This remains to be explored.  The EtherTypes are
assigned by Xerox (as always).

The total length of the SAP Header and the SNAP header is 8-octets,
making the 802.2 protocol overhead come out on a nice octet boundary.

If we can not quickly resolve the issue of the values for K1 and K2,
we will push for the assignment of a sap value (a K1 value) to
indicate "IP related protocols" and do our own multiplexing (much like
that proposed above).

In any case, we will not create incompatible interpretations of
headers already in use on 802 networks.

***  end  ***
-------

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Oct-86 06:57:34 EDT
From:      swb@DEVVAX.TN.CORNELL.EDU (Scott Brim)
To:        mod.protocols.tcp-ip
Subject:   communications analyzers for IP??

Has anyone programmed up a communications analyzer (protocol analyzer,
"datascope") to understand IP and overlying protocols?  I hope so, but
doubt it, so my next question: could people recommend programmable
communications analyzers?  We have ended up running IP over asynch,
synchronous DDCMP and HDLC lines, at speeds from 9.6Kbps to T1.  At
times a scope which understood IP/TCP/UDP would be tremendously
helpful.

Please reply directly (not everyone will be interested).  I'll
summarize for those who would like it.
						Thanks ... Scott

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Oct-86 17:38:03 EDT
From:      leong@ANDREW.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   re: BOOTP daemon for BSD 4.x



I am real glad that Bill Croft have made the BootP client and server software
available to the public domain. I think it is a very interesting package
especially for those who has a lot of PC's around running the MIT PCIP. Since
the IP addresses of those machines are associated with floppies which get
duplicated regularly by people who don't really know what IP addresses are
never mind about "CUSTOM NETDEV" and such ultiliites. The risk of having
duplicated IP addresses and subnet address inconsistency due to "wandering"
floppy can be very significant.  BootP essentially allows one to have a
better (not perfect) control to IP address allocation and usage. 

John Leong

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 1986 16:02-PDT
From:      William "Chops" Westfield <BillW@SU-SCORE.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, steve@BRL.ARPA
Subject:   Re: [Jeff Mayersohn <mayersoh@cc5.bbn.com>: more on arpanet]
Could the large amount of domain traffic on the stanford and SRI-NIC
IMPS be responsible for their execeptionally poor performance?

BillW
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Oct-86 13:25:00 EDT
From:      BEAME@MCMASTER.BITNET
To:        mod.protocols.tcp-ip
Subject:   Ultirx TCP/IP problems ?

Well Ultrix fans, I am having problems with Ultrix TCP/IP TELNET. Here is
a list of packets as seen by the PC. The packets preceeded with a "*"
are from the Ultrix machine. I am attempting to cat the file /etc/rc .
The first table the Pc's window is 82, while the second table the window
is set to 512.
The seq and ack are the low word of seq and ack displayed in deciaml.
The flag is display if hex.
The #char is decimal, and time is in seconds with 1/10 sec ticks.

PC Window = 82

who  seq     ack   flag  wind.  #char time in seconds
-----------------------------------------------------
        41   27182  18     82      1  55.70 ; Pc sends last "c" of "cat rc"
 *   27182      42  18   4096      1  55.70 ; Ultrix echos "c"
        42   27183  18     82      0  55.70 ; Pc acks
        42   27183  18     82      1  55.90 ; Pc sends "<CR>"
 *   27183      43  18   4096      2  56.00 ; Ultrix echos "<CR><LF>"
        43   27185  18     82      0  56.00 ; Pc acks
 *   27185      43  10   4096     82  01.20 ; Utrix sends text 5.2 sec. later
        43   27267  18     82      0  01.20
 *   27267      43  10   4096     82  06.20
        43   27349  18     82      0  06.20
                  ...

PC Window = 512

who  seq     ack   flag  wind.  #char time
-------------------------------------------
        41   20270  18    512      1  10.00 ; Pc enter last "c" in "cat rc"
 *   20270      42  18   4096      1  10.00 ; Ultrix echo of "c"
        42   20271  18    512      0  10.00 ; Ack of echo
        42   20271  18    512      1  10.30 ; Pc send of <CR>
 *   20271      43  18   4096      2  10.40 ; Ultrix echos <CR><LF>
        43   20273  18    512      0  10.40 ; Pc ack of <CR><LF>
 *   20785      43  14   4096      0  20.00 ; Ultrix resets the connection
        43   20273  18    512      0  23.00
 *   20273       0  04   4096      0  23.00


   Any comments and solutions, except using another PC version are welcome.
Please send responces to me and I will summerize the results back to the
list.

          - thanks
                    Carl Beame   BEAME@MCMASTER.BITNET

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Oct 86 13:25 EDT
From:      <BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Ultirx TCP/IP problems ?
Well Ultrix fans, I am having problems with Ultrix TCP/IP TELNET. Here is
a list of packets as seen by the PC. The packets preceeded with a "*"
are from the Ultrix machine. I am attempting to cat the file /etc/rc .
The first table the Pc's window is 82, while the second table the window
is set to 512.
The seq and ack are the low word of seq and ack displayed in deciaml.
The flag is display if hex.
The #char is decimal, and time is in seconds with 1/10 sec ticks.

PC Window = 82

who  seq     ack   flag  wind.  #char time in seconds
-----------------------------------------------------
        41   27182  18     82      1  55.70 ; Pc sends last "c" of "cat rc"
 *   27182      42  18   4096      1  55.70 ; Ultrix echos "c"
        42   27183  18     82      0  55.70 ; Pc acks
        42   27183  18     82      1  55.90 ; Pc sends "<CR>"
 *   27183      43  18   4096      2  56.00 ; Ultrix echos "<CR><LF>"
        43   27185  18     82      0  56.00 ; Pc acks
 *   27185      43  10   4096     82  01.20 ; Utrix sends text 5.2 sec. later
        43   27267  18     82      0  01.20
 *   27267      43  10   4096     82  06.20
        43   27349  18     82      0  06.20
                  ...

PC Window = 512

who  seq     ack   flag  wind.  #char time
-------------------------------------------
        41   20270  18    512      1  10.00 ; Pc enter last "c" in "cat rc"
 *   20270      42  18   4096      1  10.00 ; Ultrix echo of "c"
        42   20271  18    512      0  10.00 ; Ack of echo
        42   20271  18    512      1  10.30 ; Pc send of <CR>
 *   20271      43  18   4096      2  10.40 ; Ultrix echos <CR><LF>
        43   20273  18    512      0  10.40 ; Pc ack of <CR><LF>
 *   20785      43  14   4096      0  20.00 ; Ultrix resets the connection
        43   20273  18    512      0  23.00
 *   20273       0  04   4096      0  23.00


   Any comments and solutions, except using another PC version are welcome.
Please send responces to me and I will summerize the results back to the
list.

          - thanks
                    Carl Beame   BEAME@MCMASTER.BITNET

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Oct-86 19:42:35 EDT
From:      $JCH@CLVM.BITNET (Jeffrey C Honig)
To:        mod.protocols.tcp-ip
Subject:   DDN X.25

I've been informed that DDN X.25 does not currently work in PSN 6.0 but
will be fixed in PSN 6.1.  Is that correct?  When is PSN 6.1 supposed
to be installed?

Thanks

Jeff

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Oct 86 13:23:29 ZONE
From:      GAYE%FRSAC11.BITNET@WISCVM.WISC.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP-IP MAILING LIST
Hi.

I would like to be registered in the tcp-ip mailing list.
Sincerely

Gerard Gaye

gaye%frsac11@wiscvm.arpa


-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Oct-86 11:15:02 EDT
From:      GAYE@FRSAC11.BITNET
To:        mod.protocols.tcp-ip
Subject:   TCP-IP MAILING LIST

Hi.

I would like to be registered in the tcp-ip mailing list.
Sincerely

Gerard Gaye

gaye%frsac11@wiscvm.arpa

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 1986 11:53-EDT
From:      CLYNN@A.BBN.COM
To:        CERF@A.ISI.EDU
Cc:        deering@PESCADERO.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP source routing questions
Vint,

This has become a rather long message, but a brief answer to your
questions is that all of the routing takes place in the IP layer; as
far as TCP is concerned, nothing is different (except that TCP should
be notified that IP options were received); thus TCP has no difficulty
mapping the datagram to the proper connection.  I do not think that I
have a different interpretation of the source routing option; I do
think that before the routing options can be specified so that they
provide maximum functionality one has to consider several factors
which are not usually mentioned.

1)  One is that it is highly desirable for an ultimate destination
    IP entity that receives a source routed datagram to be able to
    construct a return source route.  This requires that the IP
    addresses of the interfaces over which a datagram was sent,
    by the originating IP entity and each intermediate entity
    in the source route, be available to the ultimate destination.

2)  Another is the "name" vs "address" problem and how it is handled
    in the DARPA Protocol Suite: the (TCP) pseudo-header.  This means,
    for example, that the "name" which TCP chooses to use to identify
    the ends of a connection, and are "specified" in the pseudo-header,
    must be communicated from the source to the ultimate destination.
    This information is normally (and nobody has suggested changing it)
    carried in the IP "Source Address" and "Destination Address" fields
    (of the datagram delivered to the TCP in the ultimate destination).

3)  The "catch-22" is that originating entity may be multi-homed.
    This means that the "address" (interface) which the IP routing
    algorithms use to send a (TCP) datagram may not be the same as
    the "address" (name) TCP selected (or was given by a higher
    level application) to identify the connection.  Consequently the
    IP "Source Address" field cannot (always) be used for the sending
    interface address, it has to be communicated elsewhere -- in the
    source route option's Route Data area.

The critical point for obtaining the maximal functionality from source
routing is that there must be room in the source route option for the
originating IP entity (host or gateway) to insert the address it uses
to actually send the datagram; the IP Source Identifier (aka Address)
field cannot be used for this purpose due to its significance at
higher protocol levels.

Discussions of "what should be passed to IP", for example as the
"destination" and "source route", so that it can construct an IP
Source Route Option are essentially "local implementation" issues,
which may vary from operating system to operating system.  (Although
portability of application software would suggest that all
implementations use the same method; but user interfaces are not
currently part of the IP/TCP specs.)  What an IP datagram on a network
should look like is specified in the specs.

     host A           gate B           gate C           host D
    +------+         +------+         +------+         +------+
    |      |         |      |  net 2  |      |         |      |
    |    A1|---------|B1  B2|----+----|C2  C3|---------|D3    |
    | A2   |  net 1  |      |    |    |      |  net 3  |  D4  |
    +------+         +------+    |    +------+         +------+
       |                         |                         |
       +-------------------------+

4)  Consider the above topology and a TCP connection between A and D
    which, for whatever reason, TCP has "named" by A2 and D3.  A
    datagram from A to D on nets 2 and 3 would contain IP Source Address
    A2 and IP Destination Address D3; return datagrams would have IP
    Source Address D3 and IP Destination Address A2.  Normal Internet
    routing would get datagrams to their destination.

5)  Next consider the case where a source route is used to explicitly
    route the datagrams via C.  (The contents of IP datagram on the
    nets is left as an exercise to the reader.)

6)  Now consider the case where the source route specifies B(1) instead
    of C(2).  Is it the case that the only difference between 5) and 6)
    is that C2 has been replaced by B1 and C3 by B2?  It shouldn't be --
    there should be an A1 in case 6) but not in 5).  From the above
    discussion, the TCP datagram from A to D on net 1 should contain

        IP Source Address            A2
        IP Destination Address       B1
        LSR Option  Type             131
                    Length           "11"
                    Pointer          "8"
                    Route Data       A1,->D3

    On nets 2 and 3 it would be

        IP Source Address            A2
        IP Destination Address       D3
        LSR Option  Type             131
                    Length           "11"
                    Pointer          "12"
                    Route Data       A1,B2,->

    When the Route Data is inverted to form a return route note that
    a final entry for the ultimate destination (A2) must be inserted.
    A datagram from D to A on nets 3 and 2 would have

        IP Source Address            D3
        IP Destination Address       B2
        LSR Option  Type             131
                    Length           "15"
                    Pointer          "8"
                    Route Data       D3,->A1,A2

    On net 1

        IP Source Address            D3
        IP Destination Address       A1
        LSR Option  Type             131
                    Length           "15"
                    Pointer          "12"
                    Route Data       D3,B1,->A2

    What should A do with this?  (Consider what is should do if the
    "A2" were "Zn".)  EVERY IP Entity (no distinction between gateways
    and hosts) processes routing options in the way specified in RFC 791,
    pg 19, first paragraphs:

    "If the address in the destination address field has been
     reached and the pointer is not greater than the length,
     the next address in the source route replaces the address
     in the destination address field, and the recorded route
     address replaces the source address just used, and the
     pointer is increased by four.  The recorded route address
     is the internet module's own internat address as known in
     the environment into which this datagram is being forwarded."
    The "easy" part gets

        IP Source Address            D3
        IP Destination Address       A2
        LSR Option  Type             131
                    Length           "15"
                    Pointer          "16"
                    Route Data       D3,B1,?,->

    The question mark has to be filled in and the datagram sent to A2.
    What should appear where the question mark is shown is probably
    a "local implementation" decision;  most operating systems have
    some capability to support TCP connections between processes
    within the host, even if there is no functioning network interface
    or even if no physical network connection exists.  The os can do
    several things, the only requirements are that it be consistent,
    that any "applications" understand what it does, and that no
    "funnny addresses" end up being "interpreted" in the wrong context.

There is much more that could be discussed if there is sufficient
interest.  Does anyone have a different solution to the "Source
Interface Address" problem.  Is the additional robustness worth the
cost?

Charlie
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Oct-86 12:40:21 EDT
From:      ahill@CC7.BBN.COM ("Alan R. Hill")
To:        mod.protocols.tcp-ip
Subject:   Re: DDN X.25

Jeff,
	I can assure you that DDN Basic and DDN Standard X.25 work
in PSN 6.0.  Also, there is no version of the PSN called 6.1.  The
next version of the PSN is 7.0 and it is expected to be deployed in
the ARPANET in the next few months.

Alan

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Oct 86 12:40:21 EDT
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: DDN X.25
Jeff,
	I can assure you that DDN Basic and DDN Standard X.25 work
in PSN 6.0.  Also, there is no version of the PSN called 6.1.  The
next version of the PSN is 7.0 and it is expected to be deployed in
the ARPANET in the next few months.

Alan

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Oct-86 14:00:00 EDT
From:      BEAME@MCMASTER.BITNET
To:        mod.protocols.tcp-ip
Subject:   re: Ultrix TCP/IP problems


  HELP !  What is ethernet protocol 1001h and why is my Ultrix Vax using it to
send TELNET data?

  During a regular TELNET TCP/IP session from my PC (Window size of 512)
to the VAX (Window size of 4096) I attempt to "cat" a large file, the Vax
starts sending packets of protocol type 1001h which seems to be of the form:

dest address   source address type    data
[ 6 bytes   ]  [ 6 bytes    ] [1001h] [512 bytes data] [44 bytes ?]


  My uVAX and PC are on the same local ethernet, no gateways.

           - Carl Beame

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Oct 86 14:00 EDT
From:      <BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   re: Ultrix TCP/IP problems
  HELP !  What is ethernet protocol 1001h and why is my Ultrix Vax using it to
send TELNET data?

  During a regular TELNET TCP/IP session from my PC (Window size of 512)
to the VAX (Window size of 4096) I attempt to "cat" a large file, the Vax
starts sending packets of protocol type 1001h which seems to be of the form:

dest address   source address type    data
[ 6 bytes   ]  [ 6 bytes    ] [1001h] [512 bytes data] [44 bytes ?]


  My uVAX and PC are on the same local ethernet, no gateways.

           - Carl Beame
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Oct-86 17:05:23 EDT
From:      jr@saturn.UUCP (J.R. Westmoreland)
To:        mod.protocols.tcp-ip
Subject:   Info needed on PCIP

I would like some information on PCIP.
I would like to know if it is a publicly available package or if it is for slae.If it is for sale I would like to know the cost.  Also, I would like to know where the package can be obtained.

Thanks,
J. R. Westmoreland
Utah Power & Light Company
Salt Lake City, Utah

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 1986 05:50-EDT
From:      CERF@A.ISI.EDU
To:        CLYNN@BBNA.ARPA
Cc:        deering@PESCADERO.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP source routing questions
Charlie,

thanks for the tutorial! The critical item  for the case of multi-homed
hosts, is that the IP address be constant, regardless of which port the
host sends/receives messages. This is because TCP binds connections to
IP source/destination addresses. Not all networks can provide logical
addressing and this motivates concepts of logical addressing at the IP level
to compensate. It was for that reason that I asked my question.

Vint
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Oct-86 06:13:25 EDT
From:      HANK@BARILVM.BITNET (Henry Nussbacher)
To:        mod.protocols.tcp-ip
Subject:   Looking for Tcp/Ip Implementations for Intel System 310/330/380

I am looking for information about Tcp/Ip implementations for Intel 310,
330,380.  I have an April 86 version of the TCP-IP Implementors Guide
and there is no mention of Intel in there.  I am not on either of these
lists so please send replies directly to me.

Please specify as much information as possible, i.e. cost, ordering
information, system dependencies, etc.

Many thanks,
Henry Nussbacher

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Oct-86 16:57:08 EDT
From:      "Robert_S._Printis.osbunorth"@XEROX.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   re: Ultrix TCP/IP problems

Looks like you have been bitten by the "illegal" Ethernet  packet type
that Berkelely used for the so-called "trailer" protocol.  I believe
that they confiscated the numbers that I assigned for "experimental" use
and used them in a product.  (At one time I assigned Ethernet host
numbers)

Anyone using the version on Unix that has the trailers feature will
notice these packet types from time to time.

Bob

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Oct 86 12:13:25 O
From:      Henry Nussbacher  <HANK%BARILVM.BITNET@WISCVM.WISC.EDU>
To:        tcp-ip@sri-nic.arpa
Cc:        info-xenix310@simtel20.arpa
Subject:   Looking for Tcp/Ip Implementations for Intel System, 310/330/380
I am looking for information about Tcp/Ip implementations for Intel 310,
330,380.  I have an April 86 version of the TCP-IP Implementors Guide
and there is no mention of Intel in there.  I am not on either of these
lists so please send replies directly to me.

Please specify as much information as possible, i.e. cost, ordering
information, system dependencies, etc.

Many thanks,
Henry Nussbacher
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Oct-86 19:45:32 EDT
From:      bandy@LLL-CRG.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Yes, this is real.  This was as of noon PDT today

ping seismo.css.gov
64 bytes from xc00c8d19: icmp_seq=1. time=180630. ms
64 bytes from xc00c8d19: icmp_seq=2. time=179690. ms
64 bytes from xc00c8d19: icmp_seq=5. time=176690. ms
64 bytes from xc00c8d19: icmp_seq=6. time=175690. ms
^?
----seismo.css.gov PING Statistics----
16 packets transmitted, 4 packets received, 75% packet loss
round-trip (ms)  min/avg/max = 175690/178175/180630


Yow!  Something is definitely messed up somewhere!!!
	andy

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Oct-86 11:33:12 EDT
From:      schoff@CSV.RPI.EDU (Martin Schoffstall)
To:        mod.protocols.tcp-ip
Subject:   Root NameServers on the East Coast


I don't know if that has been talked about before but given
the current state of the Arpanet wouldn't it be rational
to have a root server on the East Coast?

marty

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Oct-86 15:03:22 EDT
From:      nesheim@THINK.COM (Bill Nesheim)
To:        mod.protocols.tcp-ip
Subject:   Re: Ultrix TCP/IP problems


Note that REAL 4.3bsd unix will only use the trailer packet type
if it is talking to another 4.3bsd machine: it now does trailer
negotiation via ARP.

In other words, your PC's won't ever see them.

	Bill Nesheim

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Oct-86 22:24:46 EDT
From:      hedrick@topaz.rutgers.edu (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   DECnet over IP?

We are in the process of building a campus network for Rutgers.  For
fairly obvious reasons (at least I hope they are obvious to readers of
this group), it is primarily IP based.  I am finding it an increasing
pain in the neck to provide for VMS users who want us to support
DECnet among their machines.  I understand their desire, since VMS has
DECnet very well integrated.  But it seems nearly impossible to
support DECnet in a gateway, even when the gateway has been built to
support PUP, XNS, IP, Chaos, and every other conceivable protocol.
Anyway, it strikes me that the obvious solution would be to run DECnet
on top of IP.  I can even think of a way to do it.  But I don't have
enough time at the moment to implement it.  Has anybody done this?
[The way I would do it is to write a device driver that pretended to
be a multi-line synchronous line controller.  Inside it, there would
be a table that associated one IP address with each supposed
synchronous line.  The driver would simply stick the right IP header
in front of each message and send it out the Ethernet interface.  This
sounds like something a competent VMS hacker could do in a week,
though I've been involved in enough things like this to know how
misleading that can be.]  I would probably be willing to pay, if
somebody would like to do it for us.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Oct-86 00:27:46 EDT
From:      ron@BRL.ARPA (Ron Natalie)
To:        mod.protocols.tcp-ip
Subject:   Re:  Root NameServers on the East Coast

I was just at the DOMAIN server committee at the Internet Engineering
Task Force at SRI last week.  There will be nameservers appearing on
both the EAST COAST and on MILNET very soon.

-ROn

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Oct-86 01:58:58 EDT
From:      jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes)
To:        mod.protocols.tcp-ip
Subject:   summary?

Now that the IETF meeting is over, how about some info from those
who were there on the relevant issues (separately, of course) to
these lists? Thanks.

/jordan

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 86 09:19:00 PST
From:      <gary@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   DECnet over IP

You might want to talk with the folks at Wollongong.  They have a 
package called 'D-Bridge' which allows  TCP/IP packets to be
"team submitted" via DECnet circuits.  This combined with their
shared Deuna option might be an interim solution.

Gary Krall
------
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Oct-86 13:19:00 EDT
From:      gary@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   DECnet over IP


You might want to talk with the folks at Wollongong.  They have a 
package called 'D-Bridge' which allows  TCP/IP packets to be
"team submitted" via DECnet circuits.  This combined with their
shared Deuna option might be an interim solution.

Gary Krall
------

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Oct-86 17:14:56 EDT
From:      ospwd@emory.CSNET (Peter Day {EUCC})
To:        mod.protocols.tcp-ip
Subject:   TELNET 3270 for PC/IP

Does anyone know of an implementation of TCP/IP for the IBM-PC that
has a TELNET with 3270 emulation? I am aware that the University
of Maryland intends to add such a facility to the MIT PC/IP,
but I am looking for something that would be available in the next
(say) 4 months.

Please reply directly to me.

Thanks,
Peter W. Day

CSNET:	ospwd@emory					
ARPA:	ospwd%emory.csnet@csnet-relay.arpa
UUCP:	{ akgua, gatech }!emoryu1!ospwd
BITNET:	ospwd@emoryu1
USPS: 	Computing Center, Emory University, Atlanta, GA 30322
PHONE:  404/727-7678

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Oct 86 17:14:56 EDT
From:      Peter Day {EUCC} <ospwd%emory.csnet@CSNET-RELAY.ARPA>
To:        mod.protocols.tcp-ip, tcp-ip@SRI-NIC.ARPA
Subject:   TELNET 3270 for PC/IP
Does anyone know of an implementation of TCP/IP for the IBM-PC that
has a TELNET with 3270 emulation? I am aware that the University
of Maryland intends to add such a facility to the MIT PC/IP,
but I am looking for something that would be available in the next
(say) 4 months.

Please reply directly to me.

Thanks,
Peter W. Day

CSNET:	ospwd@emory					
ARPA:	ospwd%emory.csnet@csnet-relay.arpa
UUCP:	{ akgua, gatech }!emoryu1!ospwd
BITNET:	ospwd@emoryu1
USPS: 	Computing Center, Emory University, Atlanta, GA 30322
PHONE:  404/727-7678

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Oct-86 23:39:20 EDT
From:      bromley@SVAX.CS.CORNELL.EDU (Mark Bromley)
To:        mod.protocols.tcp-ip
Subject:   NFILE server BSD4.3??

Does anyone have an NFILE (the latest Symbolics file protocol) server
for BSD 4.3?  Thanks.

Mark Bromley
bromley@svax.cs.cornell.edu

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 1986 0942-EDT
From:      Kevin Paetzold <PAETZOLD@MARLBORO.DEC.COM>
To:        Bill Nesheim <nesheim@Think.COM>, "Robert_S._Printis.osbunorth"@xerox.com
Cc:        BEAME%MCMASTER.BITNET@wiscvm.wisc.edu, tcp-ip@sri-nic.ARPA, nesheim@godot
Subject:   Re: Ultrix TCP/IP problems
However 4.2 BSD would send trailer encapsulated packets to any other station
unless it was disabled.  TOPS-20 has a detecting mechanism for this where it
will issue a BUGINF if it receives a trailer encapsulated packet (on any of 
the trailer encapsulated protocol types).  The detecting mechanism is 
probably not a bad idea for other implementations until trailer encapsulated
packets are not around anymore.

   --------
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Oct-86 10:51:49 EDT
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: summary?


	Here's a brief summary, but remember that these are my personal
memories, and are not official and may contain errors. I also hope I'm
not offending anyone by writing this up before the official scribe gets
to it; if so I apologise.
	There were three main topics of discussion; ISO transition, Domain
Name transition, and EGP. These were discussed in the three separate
workshops; I can report on the last in detail, but did not attend the
first two. I will give my understanding of what happened in the first two,
but it may contain errors. We also heard a report of the state of the
ARPANet, but it doesn't contain much that hasn't already been posted to
TCP-IP.

	The ISO transition scheme is looking at ways to start introducing
ISO traffic into the system. As I understand it, the general theory is
that they will upgrade the routers (IP gateways) to handle ISOgrams as
well as IPgrams and run the two protocols side by side; there are also
plans for service-level protocol converting gateways for things as mail.
There is also an extant spec for using Dod IP addresses in ISOgrams (the
ISO addressing architecture is pretty kitchen sink style, and why assign
new numbers when we already have perfectly good numbers).
	The Domain Name transition is coming along pretty well. There are
several steps seen as needing to happen; the last non-domain style names
need to be flushed from HOSTS.TXT, and the MILNET needs to transition
toward use of domain names (at the moment they all use HOSTS.TXT, and if
you send mail from a host which is not in HOSTS.TXT to the MILNET they
can't reply). Once everyone is using the domain system we can flush
HOSTS.TXT. Some issues which were discussed were the need to provide more
root servers on the East coast and also root servers on MILNET (to keep
the security concious people happy). Also, it is proving difficult for the
NIC to build a tree walker that automatically constructs HOSTS.TXT by
walking the name tree since lots of people don't support zone transfer.

	As far as EGP goes, discussion centered around two main topics.
One was that the updates are nearing overflow; the entire routing table is
sent in a single packet, and as the net gets larger that will overflow.
The other was that the current topology restrictions in EGP (you aren't
suuposed to have Autonomous Systems in cycles (loops), or more than one AS
away from the Core) are crippling.
	The first was solved by designing an update mechanism where the
table is sent slowly, in smaller packets spead out evenly. This has the
added advantage of not causing a big processing disturbance when you get
this massive table that you have to parse. Everyone who reviewed this
thought that it was a good mechanism, and it is close enough to existing
algorithms and solving a sufficently simple problem that it was felt
that it could be implemented with the assurance that it will work.
	The problem is that the people who were studying the cycle problem
decided that to really fix that right, they needed to switch to a
different routing algorithm, which would demand entirely different data in
the updates. However, that is a sufficiently complex problem (and
algorithm) that it was felt that extensive review, analysis and simulation
were needed before the solution was felt to be solid. Such an effort would
consume some months, and was thus not amenable to doing on the spot in the
committee. This presented a problem, and caused a heated discussion.
	It was argued that the cycle restrictions were so onerous, that as
soon as a solution had been designed it should be implemented right away.
The timeframe for that was felt to be a year or two (allowing for design,
review, simulation to prove correct functioning, implementation and
deplyment). It was further argued that the update size restriction is not
that onerous; the updates would not be larger than the MTU of most nets
(e.g. ARPANet) for at least a year, and even after that they could be
handled by use of IP fragmentation. That being the case, it was felt that
diverting effort into an intermediate standard that did not solve the
most pressing problem was not a wise move.
	It was counterargued that if the new design effort failed, we would
have failed to solve the one problem we did agree on a solution for, and
it would be too late at that point to attempt a crash deployment (due to
release schedules, etc).

	The following compromise was sort of agreed on, after much blood
over the transom. A spec will be written for the interim EGP; this will be
an official IP spec. BBN will move to get it in the next core gateway
release. However, the older version of EGP will be continue to be
supported, and it will not be mandatory to implement the new version. In
addition, a small number of mandatory upward compatible changes to the
existing spec were agreed on to a) make version numbers useful, and b)
allow version negotiation. These will all be available for comment in
an RFC, to be followed by changes to the EGP RFC.
	At the same time, a group of interested parties will start work on
the followon protocol (FGP), with a target of 6 months to a year to begin
deploying it. The proposal will be available for review, but will not be
an official spec. Should it prove good enough, it may be adopted as a
spec, but that is not guaranteed. Should it be adopted, it would not be
necessary to implement the interim standard; users could skip straight
from the old one to the new one. This group is private, but will make
every effort to consult people on requirements as well as to get reviews
of the design.
	FGP will retain the basic EGP model; groups of gateways called
TAS's (transit autonomous systems) will be hooked via FGP, but can run any
protocol of their own devising between themselves. The FGP routing
algorithm will be based on the existing SPF algorithm done by BBN for the
IMPs, and will provide support for cycles, and if possible, TOS and
multi-path routing. A means was devised to phase it in gradually; groups
of TAS's running it will appear as a single AS using the existing EGP, and
will need to be hooked directly to the existing Core. However, within the
limits of that AS (which might eventually expand to contain most of the
Internet) the new rules will apply.

	As far as my memory goes, that was about it, although I will
admit that I was mostly preoccupied with the EGP thing. I may have missed
other topics; if so, would knowledgeable people please comment?


	Noel
-------

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 86 18:12:00 EDT
From:      "G. B. Reilly" <reilly@wharton-10.ARPA>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Anyone have ULTRIX v1.2 talking to a PSN using ACC 6250

using X.25 BASIC service?

------
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Oct-86 20:10:06 EST
From:      jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen)
To:        mod.protocols.tcp-ip
Subject:   TCP/IP on 802.3 now???

A week ago, I encountered a strange situation: A contact informed me
that his Gould MPX-32 needed to know our Ethernet address (in its host
table) in order to communicate; How did he set the corresponding info
in our host table?

Further investigation revealed that the Gould product has a mode where
it sends IP packets using 802.3 packet formats, without ARP.  Luckily
for us, this mode can be changed back to what they call Ethernet 1.0
by re-strapping the board and changing a configuration command in the
startup file.  The Gould support people say that the transceiver also
has to be replaced (did some lines in the cable actually get
re-defined?), but experiment indicates this isn't necessary, at least
on a small Ether.

Of course, I was mildly amazed to see anyone actually going this far
in honor of the guy from the corporate standards committee with the
clipboard and the checklist, but I've seen sillier...  Posting this
primarily to inform the world that the swamp has gained a new kind of
mud.

jbvb@ai.ai.mit.edu
FTP Software Inc.
(617) 864-1711

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 1986 07:44-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        $jch%clvm.bitnet%violet.berkeley.edu@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:      DDN X.25
Who  informed  you that PSN 6 doesn't work?  How doesn't it work?
*sigh* PSN 6 had some minor bugs with X.25 when it came  up,  but
as  far  as  I know patches to fix all of them have been fielded.
There is no such thing as PSN release 6.1.  The next  release  of
the  PSN  software is PSN 7 which is due out the first quarter of
next year.

Mike StJohns, DDN PMO
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Oct-86 11:11:53 EST
From:      cassel@DEWEY.UDEL.EDU (Boots Cassel)
To:        mod.protocols.tcp-ip
Subject:   network monitors

I am interested in information about and experiences with network monitors
and measurement devices.  I am aware of the following products.  If any one
knows of others I should know about, or has comments on these, I would be
grateful.

Commercial Products:  Exelan Nutcracker and LANalyzer
                      CMC LANscan
                      HP LAN Protocol Analyzer
                     

Research work:  ILMON by Lewis Barnett
                Mondow by Mike Minnich at Delaware
                The ONR Measurement Center at Delaware
                Feldmeier's work at MIT

Pointers would be appreciated.  I will share the information with others if 
there is interest.

Boots Cassel
cassel@dewey.udel.EDU

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Oct 86 11:11:53 EDT
From:      Boots Cassel <cassel@dewey.udel.EDU>
To:        tcp-ip@dewey.udel.EDU
Cc:        cassel@dewey.udel.EDU
Subject:   network monitors
I am interested in information about and experiences with network monitors
and measurement devices.  I am aware of the following products.  If any one
knows of others I should know about, or has comments on these, I would be
grateful.

Commercial Products:  Exelan Nutcracker and LANalyzer
                      CMC LANscan
                      HP LAN Protocol Analyzer
                     

Research work:  ILMON by Lewis Barnett
                Mondow by Mike Minnich at Delaware
                The ONR Measurement Center at Delaware
                Feldmeier's work at MIT

Pointers would be appreciated.  I will share the information with others if 
there is interest.

Boots Cassel
cassel@dewey.udel.EDU
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Oct 86 17:14:54 PDT
From:      karels@monet.Berkeley.EDU (Mike Karels)
To:        tcp-ip@sri-nic.arpa
Cc:        4bsd-bugs@ucbarpa.Berkeley.EDU, net-bugs-4bsd@ucbvax.Berkeley.EDU
Subject:   4.3BSD network bug (#1, tcp_output)
Index:	sys/netinet/tcp_output.c 4.3BSD FIX

This is the first of a set of three bug reports with fixes for the network
in 4.3BSD.  All 4.3 sites should install the modifications described in
these reports.  The bug described in this report is the most serious,
as it can cause unnoticed loss of data.

Description:

The final change in the send code in TCP in 4.3 was made incorrectly.
In tcp_output (/sys/netinet/tcp_output.c), the output packet flags
are chosen before the packet length is adjusted to reflect the maximum
segment size.  Under some cirsumstances, this results in sending a FIN
with a packet which is not the last data packet.  This is most often
noticed when the connection implements a one-way transfer of data
and the sender closes while the data is still draining.

Fix:

Move the lines in tcp_output that look up the flags to be sent
to a location after the final length adjustment, as follows:

*** /nbsd/sys/netinet/tcp_output.c	Thu Jun  5 00:31:36 1986
--- tcp_output.c	Wed Aug 20 09:31:34 1986
***************
*** 5,7 ****
   *
!  *	@(#)tcp_output.c	7.1 (Berkeley) 6/5/86
   */
--- 5,7 ----
   *
!  *	@(#)tcp_output.c	7.2 (Berkeley) 8/20/86
   */
***************
*** 82,85 ****
  	flags = tcp_outflags[tp->t_state];
- 	if (SEQ_LT(tp->snd_nxt + len, tp->snd_una + so->so_snd.sb_cc))
- 		flags &= ~TH_FIN;
  
--- 82,83 ----
***************
*** 118,119 ****
--- 116,119 ----
  	}
+ 	if (SEQ_LT(tp->snd_nxt + len, tp->snd_una + so->so_snd.sb_cc))
+ 		flags &= ~TH_FIN;
  	win = sbspace(&so->so_rcv);
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Oct 86 17:17:48 PDT
From:      karels@monet.Berkeley.EDU (Mike Karels)
To:        tcp-ip@sri-nic.arpa
Cc:        4bsd-bugs@ucbarpa.Berkeley.EDU, net-bugs-4bsd@ucbvax.Berkeley.EDU
Subject:   4.3BSD network bug (#3, MCLGET/mbuf.h)
Index:	sys/h/mbuf.h 4.3BSD FIX

This is the last of a set of 3 bug reports with fixes for the network
in 4.3BSD.  All 4.3 sites should install the modifications described
in these reports.  Although rare, the bug described in this report
may cause unexplained crashes or random failures.

Description:

The macros for addition of page clusters to mbufs were revised in 4.3BSD.
A new macro, MCLGET, is called to add a single page cluster to an mbuf.
If there are no free clusters, the macro calls m_clalloc to attempt
to create a new cluster.  Unfortunately, the MCLGET macro does not run
at high priority, but m_clalloc may only be called from splimp to block
reentrance of the memory allocation routines.  The call to m_clalloc
should be made from MCLALLOC, which does run at high priority.

Fix:

In the file /sys/h/mbuf.h, move the test of mclfree and call to m_clalloc
from the MCLGET macro to the MCLALLOC macro, as shown by the following diffs:

*** mbuf.h.old	Thu Sep 11 06:07:29 1986
--- mbuf.h	Thu Sep 11 06:20:07 1986
***************
*** 5,7 ****
   *
!  *	@(#)mbuf.h	7.1 (Berkeley) 6/4/86
   */
--- 5,7 ----
   *
!  *	@(#)mbuf.h	7.3 (Berkeley) 9/11/86
   */
***************
*** 97,98 ****
--- 97,100 ----
  	{ int ms = splimp(); \
+ 	  if (mclfree == 0) \
+ 		(void)m_clalloc((i), MPG_CLUSTERS, M_DONTWAIT); \
  	  if ((m)=mclfree) \
***************
*** 105,108 ****
  	{ struct mbuf *p; \
- 	  if (mclfree == 0) \
- 		(void)m_clalloc(1, MPG_CLUSTERS, M_DONTWAIT); \
  	  MCLALLOC(p, 1); \
--- 107,108 ----
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Oct 86 10:11 EDT
From:      WIBR@MIT-MULTICS.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Mailing List
Please remove WIBR from your tcp-ip relay list.  Thank you.
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Oct-86 17:31:10 EST
From:      kluger@ogle.UUCP (Larry Kluger Sun Europe)
To:        mod.protocols.tcp-ip
Subject:   CCITT G703 interface

Hi,

I want to link two Ethernets for IP connectivity that are 
about 15 km (~10 miles) apart in West Germany.

The West German PTT is offering a CCITT G703 link between
the two sites. The interface is at 2 Mbps.

Do you know of an IP router or MAC level bridge that has a G703 
interface?

Information or pointers would be appreciated.

Thanks,

Larry Kluger
Sun Microsystems Europe

lkluger@sun.com

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Oct 86 08:13:46 -0500
From:      Craig Partridge <craig@loki.bbn.com>
To:        tcp-ip@sri-nic.arpa
Subject:   Setting Initial Round-trip time

    I'm working on an implementation of RDP and am trying to find ways
to improve the round-trip time estimates.  The timeout algorithm is the
same as TCP's with the values suggested in RFC 889, but I've noticed that
choosing the wrong initial value for the estimated round trip time can
have a severe impact on throughput if the total number of packets is
relatively small and the link is lossy.

    I'd like to improve that performance by choosing better initial values.
This isn't something I know very much about so I'm soliciting advice.  How
do other people choose the initial value to put into the round trip estimate
equations?   What mechanisms do you recommend or strongly discourage or
disparage?

Craig Partridge
CSNET Technical Staff
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Oct-86 01:32:20 EST
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re:  network monitors

We find the most generally useful network monitor to be a Sun.
Traffic is good for general watching, and etherfind for looking at
individual packets.  For many purposes an IBM PC with the MIT
public-domain netwatch is quite useful.  It just shows you packets,
with some limited ability to select based on source, dest, etc.  We
understand that the HP Ethernet monitor will be really great when the
next software release comes out, but for the moment it's useful only
when you really want to look at the bits (and want to make sure you
aren't dropping any packets in a high-speed network).

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Oct-86 09:35:58 EST
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        mod.protocols.tcp-ip
Subject:   Secure LAN File Server

From the October, 1986 issue of SIGNAL:

----------------------------------------
The National Security Agency (NSA) has signed a Memorandum of 
Understanding to acquire a Secure LAN File Server that will provide high
grade encryption support for a variety of file storage devices.  The
secure file server, being developed by Simpact Associates, Inc., as part
of its participation in NSA's Commercial COMSEC Endorsement Program,
will allow users with classified applications to file data on
conventional storage devices.  Because the information is encrypted
before it is stored, the storage device does not have to be Tempest
treated, and users need not remove the medium and store it in a secure
safe when it is not in use.  Elimination of these restrictions allows
users to configure their systems from a wide range of commercially
available, high performance, high density file storage devices.  Future
related products, when used with a computer that has an accredited
secure operating system, will provide multilevel file security.  The
first of this new family of file servers will address the government's
large installed base of Wang Laboratories, Inc., computers.  Deliveries
are scheduled to start in late 1987.  Commercial availability of the
Secure LAN File Server is contingent on final NSA endorsement.
----------------------------------------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Oct-86 13:09:32 EST
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        mod.protocols.tcp-ip
Subject:   Re: The NIC and FTPing host tables

Bob Knight

Back on 25 Feb 86 you noted a large FTP load when new host tables were
released.  The responses seemed to concentrate on what might be done
with the host tables.  A more fundamental issue is the behavior of FTP
servers.  I suggest that network performance would be improved if FTP
were revised as follows:

    1. FTP should reject a request for a non-local transfer if "M"
incomming or "N" outgoing jobs are already in progress.

    Rationale: When you permit many concurrent FTP jobs long connection
times are necessary and everyone gets slow service.  Long connection
times increase the probability that equipment failure or a transitory
glitch will cause the connection to be aborted.  In the absence of a
restart marker the user will have to start from the beginning of the
file.  I estimate that sites with a single 56 Kbps PSN circuit should
limit concurrent FTP jobs to two incomming and two outgoing.

Once rejected, what's a user to do, sit around and harass the 
FTP server?  I suggest:

    2. The FTP rejection message should allow the user to queue the
request for later execution.

    Rationale: FTP jobs are not urgent.  So long as the user knows the
job will eventually be completed, it doesn't matter if it takes several
hours.

Clark, Mills, and Nagle, among others, have offered good advice on
techniques to improve the performance of TCP and avoid network
congestion.  The unstated, perhaps obvious, objective follows from
Queuing Theory: Never drive any path through the network at more than
70% of capacity.  Being able to reject a request will smooth the FTP
load and should improve network throughput.  Being able to queue jobs
will maintain the operational utility of FTP.

H. Craig McKee

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Oct-86 18:04:17 EST
From:      craig@loki.bbn.com (Craig Partridge)
To:        mod.protocols.tcp-ip
Subject:   Setting Initial Round-trip time


    I'm working on an implementation of RDP and am trying to find ways
to improve the round-trip time estimates.  The timeout algorithm is the
same as TCP's with the values suggested in RFC 889, but I've noticed that
choosing the wrong initial value for the estimated round trip time can
have a severe impact on throughput if the total number of packets is
relatively small and the link is lossy.

    I'd like to improve that performance by choosing better initial values.
This isn't something I know very much about so I'm soliciting advice.  How
do other people choose the initial value to put into the round trip estimate
equations?   What mechanisms do you recommend or strongly discourage or
disparage?

Craig Partridge
CSNET Technical Staff

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 1986 18:42-EST
From:      CERF@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   IP on DECNET

I probed and got the following back:

 
Date:     Wed Oct 29, 1986  2:17 pm  EDT
 

Subject:  DECNET over IP
 
Vint,
 
the following (included) message came as a response from a software
specialist in another district through a rather contorted chain of mail
messages.
 
 
        This kind of an architectural mish-mash would be kind of strange.
        However, you could do it.  To make sense, the IP layer would have
        to function in the same capacity as X.25 in DNA.  There would have
        to be DLM (Data Link Mapping) code added in DECnet-VAX to support
        DECnet circuits providel cy this new IP service.  I can't think
        of any other way to do it.
 
        Even so the DLM would have to be more intelligent than the one
        currently implemented for X.25 since X.25 provides a connection-
        oriented service and IP does not.
 
 
 
DNA is of course Digital Network Architecture.  Most people seemed to 
think it would take a lot longer than a week!  I wonder if this will get
any easier as Digital migrates DNA to OSI....  (I don't know anything 
about IP!)
 

 
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Oct-86 09:36:02 EST
From:      ahill@CC7.BBN.COM ("Alan R. Hill")
To:        mod.protocols.tcp-ip
Subject:   re: X.25 Standard service on ARPANET


	There are hosts on the ARPANET that have successfully interchanged
TCP/IP data between X.25 sources and 1822 destinations.  The hosts that
I am aware of use ACC interfaces.  Initial attempts to communicate failed
because the hosts were not enabled to cross host access control boundaries
established in the subnet.  This was corrected earlier this week and tests
following the change were considered sucessful.

Alan

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Oct-86 13:00:00 EST
From:      james@ZERMATT.LCS.MIT.EDU ("James William O'Toole, Jr.")
To:        mod.protocols.tcp-ip
Subject:   Re: Setting Initial Round-trip time


    Date: 30 Oct 1986 04:24-EST
    From: CERF@A.ISI.EDU
    Subject: Re: Setting Initial Round-trip time

    A background process might try to gather data - but this would by like
    pinging everyone just in case you might want to talk with them - leads
    to predictable disaster.

A background process could more easily maintain a cache of round trip
time data measured from recent traffic.  Connections from a given host
are probably concentrated on certain destinations, so you ought to be
able to do much better than pinging.  Of course, you still need to know
which measurements to take and how to use them.  Mean and variance of
round trip time on a per host basis, with recent data more heavily
weighted, perhaps?

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Oct-86 14:44:57 EST
From:      melohn@SUN.COM (Bill Melohn)
To:        mod.protocols.tcp-ip
Subject:   re: X.25 Standard service on ARPANET

There is another implementation that I am aware of that is doing Standard
Services X.25 to an ARPAnet IMP (oops, PSN).  It too talks successfully with
other 1822 systems, and does NOT use an ACC board.  Sun has announced DDN
support (including X.25 Standard and Basic) as a product, so "contact your
local Sun sales rep for more information."

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Oct-86 16:11:09 EST
From:      braden@isi.edu (Bob Braden)
To:        mod.protocols.tcp-ip
Subject:   Re:  Setting Initial Round-trip time


Members of the END2END taskforce have also been worrying  about your
problem  (setting an initial round-trip time).  It is an important
(but not usually critical) problem for connection-oriented protocols like
TCP and RDP; it is more important and more difficult for a transaction-
oriented transport protocol of the sort we have been stalking.

As Vint says, a background process to gather data is a VERY bad idea.
Nor do I think the hop count is at all useful as a predictor.

However, it may not be a bad idea to maintain a cache of historical data
about observed round trip times to hosts you have talked to recently.
This may help in the case of a small "working set" of hosts you talk to.
In the opposite case ... short transfers to a very large collection of
randomly chosen hosts -- the answer may very well be that you cannot
reasonably expect very good performance when nets are lossy, and should
not waste time trying to obtain the impossible.  And at system startup, 
before there is any historical data, you cannot do very well.

Someone needs to think a little about the right way to maintain such a
cache of historical RTT's per host, with respect to the way you maintain
it (considering dispersion of observations), and how you use the data.

Someone is going to say "You have to ask the gateways".  Well, maybe, but
that would seem to come some time after we are able to provide effective
type-of-service routing over widely-diverse paths.  Or maybe at the
same time?  Still, it wouldn't hurt for us to pose this requirement 
(an ICMP message from a host inquiring about the probable delays to a given
Internet host) to Dave Mills' INARCH task force, and see what they can
come up with.  This requirement seems to go deep into the overall routing
architecture of the Internet.

Finally, our Internet Architect has a simple answer to your problem:
don't use RDP, use NETBLT.  NETBLT shares the principal advantages of
RDP (packet-orientation and selective retransmission), but uses a 
different use of timers so that the RTT is not important.  Of course,
NETBLT has its own set of hard timer problems...

Bob Braden

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Oct-86 18:45:50 EST
From:      OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen)
To:        mod.protocols.tcp-ip
Subject:   RFC Sets




Hi,

Many people have asked for a set of "most useful RFCs", so we have put
together the following RFC sets, organized by topic. Please feel free
to suggest changes to this list.  

RFCs which are marked with an asterisk (*) are NOT included in the
1985 DDN Protocol Handbook.



                                  MAJOR RFCs

       RFC-791      Internet Protocol (IP)
       RFC-792      Internet Control Message Protocol (ICMP)
       RFC-793      Transmission Control Protocol (TCP)
       RFC-768      User Datagram Protocol (UDP)
       RFC-854      Telnet  Protocol  (see  also many Telnet Options
                    in the RFC index)
       RFC-959      File Transfer Protocol (FTP)
       RFC-821      Simple Mail Transfer Protocol (SMTP)
       RFC-822      Standard for the Format of ARPA Internet Text Messages
       RFC-960      Assigned Numbers
       RFC-961      Official ARPA Internet Protocols



                                   MAIL RFCs

       RFC-821      Simple Mail Transfer Protocol (SMTP)
       RFC-822      Standard for the Format of ARPA Internet Text Messages
       RFC-886 *    Proposed Standard for Message Header Munging
       RFC-915 *    Network Mail Path Services
       RFC-934 *    Proposed Standard for Message Encapsulation
       RFC-937      Post Office Protocol Version 2
       RFC-974 *    Mail Routing and the Domain System
       RFC-976 *    UUCP Mail Interchange Format Standard
       RFC-987 *    Mapping between X.400 and RFC 822



                            NAMING AND DOMAIN RFCs

       RFC-799      Internet Name Domains
       RFC-819 *    Domain Naming Convention for Internet User Applications
       RFC-882 *    Domain Names - Concepts and Facilities
       RFC-883      Domain Names - Implementation Specification
       RFC-920 *    Domain Requirements
       RFC-921 *    Domain Name System Implementation Schedule - Revised
       RFC-973 *    Domain System Changes and Observations
       RFC-974 *    Mail Routing and the Domain System
       RFC-952      Internet Host Table Specification
       RFC-953      Hostnames Server

                                 GATEWAY RFCs

       RFC-792      Internet Control Message Protocol (ICMP)
       RFC-823      The DARPA Internet Gateway (GGP)
       RFC-890 *    Exterior Gateway Protocol Implementation Schedule
       RFC-904      Exterior Gateway Protocol Formal Specification (EGP)
       RFC-911 *    EGP Gateway under Berkeley UNIX 4.2
       RFC-975 *    Autonomous Confederations
       RFC-985 *    Requirements for Internet Gateways -- Draft



                          LOCAL AREA and SUBNET RFCs

       RFC-894      A Standard for the Transmission of IP Datagrams
                    over Ethernet Networks
       RFC-895      Standard for the Transmission of IP Datagrams over
                    Experimental Ethernet Networks
       RFC-948      Two Methods for the Transmission of IP Datagrams over
                    IEEE 802.3 Networks
       RFC-826      An Ethernet Address Resolution Protocol
       RFC-903      A Reverse Address Resolution Protocol
       RFC-925 *    Multi-LAN Address Resolution Protocol
       RFC-917 *    Internet Subnets
       RFC-940 *    Toward an Internet Standard Scheme for Subnetting
       RFC-950 *    Internet Standard Subnetting Procedure
       RFC-919 *    Broadcasting Internet Datagrams
       RFC-922 *    Broadcasting Internet Datagrams in the Presence of Subnets
       RFC-947 *    Multi-network Broadcasting within the Internet
       RFC-966 *    Host Groups: A Multicast Extension to the Internet Protocol
       RFC-988 *    Host Extensions for IP Multicasting



                                BACKGROUND RFCs

       IEN-48       The Catenet Model for Internetworking
       RFC-896 *    Congestion Control in IP/TCP
       RFC-970 *    On Packet Switches with Infinite Storage
       RFC-813      Window and Acknowledgement Strategy in TCP
       RFC-814      Name, Addresses, Ports, and Routes
       RFC-815      IP Datagram Reassembly Algorithms
       RFC-816      Fault Isolation and Recovery
       RFC-817      Modularity and Efficiency in Protocol Implementation
       RFC-871 *    A Perspective on the ARPANET Reference Model
       RFC-872 *    TCP-ON-A-LAN
       RFC-873 *    The Illusion of Vendor Support
       RFC-874 *    A Critique of X.25
       RFC-980 *    Protocol Documentation Order Information



                        TOWARDS INTERNATIONAL STANDARDS

       RFC-905 *    ISO Transport Protocol Specification
       RFC-942 *    Transport Protocols for Department of Defense Data Networks
       RFC-939 *    Executive Summary of the NRC Report on Transport
                    Protocols for Department of Defense Data Networks
       RFC-945 *    DoD Statement on the NRC Report
       RFC-983 *    ISO Transport Services on Top of the TCP
       RFC-941 *    Addendum to the Network Service Definition Covering Network
                    Layer Addressing
       RFC-987 *    Mapping between X.400 and RFC 822
       RFC-926 *    Protocol  for  Providing  the  Connectionless-Mode
                    Network Services




All RFCs are of course available via anonymous FTP from SRI-NIC.ARPA in
the RFC: directory or you may contact us at:

DDN Network Information Center
SRI International, Room EJ291
333 Ravenswood Avenue
Menlo Park, CA 94025
(800) 235-3155 or (415) 859-3695
NIC@SRI-NIC.ARPA


Cheers,
	Ole
-------

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Oct-86 19:55:52 EST
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        mod.protocols.tcp-ip
Subject:   Poor performance related to egp?



I can't help but wonder if the poor internet performance is related to the
HORRIBLE routes that egp says to use.

I have seen improvements in round trip icmp echo times of 1000% by
ignoring the route egp says to use and manually forcing a route into
the system. In many cases, it is the difference between connecting
at all and timing out. Todays horrible case has been routing to
128.96 (bellcore.com) through lbl-milnet-gw instead of the rational
relay.cs.net. Other horrible routes have included rutgers through
purdue instead of the direct rutgers arpanet host.

Are the egp routes supposed to be reasonable? I'm not that familiar with
the theory behind them, but in practice, the suck badly. When I can get
a 10 to 1 performance improvement by hard coding specific routes to
override egp, I wonder if this is part of the internet congestion problem.

It seems like a major performance gain for everyone could be realized
by having the egp core systems advertise rational routes.

---rick

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 1986 05:52-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        braden@VENERA.ISI.EDU
Cc:        craig@LOKI.BBN.COM, cerf@A.ISI.EDU tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Setting Initial Round-trip time
Of  course  our Internet Architect who recommended NETBLT happens
to be one of its authors.  Hmmm....  Mike
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Oct 86 09:16:55 PST
From:      Bob Braden <braden@isi.edu>
To:        CERF@a.isi.edu
Cc:        braden@isi.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Setting Initial Round-trip time
	
	The problem with the cache is that a) you don't know if the values
	correspond to the routes your traffic is/will take. b) you may not
	have enough traffic to enough destinations to maintain statistically
	valid (fresh) delay information. It may be possible that things will
	be static enough that cache will actually work well most of the time,
	but if the internet exhibits significant statistical variation in
	delay/throughput, the cache may be not only misleading but downright
	harmful.
	
Vint, 

Everything you say is true, but I fail to see how bad cache information
will be more harmful than no information at all.

Bob Braden
	
	
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Oct-86 06:53:49 EST
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        mod.protocols.tcp-ip
Subject:   Re: Setting Initial Round-trip time

You noted that the number of packets was small and the link was lossy.

Is the link lossy because of congestion or because of noise?

If the former (congestion) then the advice of John Nagle (RFC 896)
is relevant.

If the latter (noise) then more complex measures are needed; for
example, a Session/Presentation layer Forward Error Correction
procedure.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Oct-86 09:00:52 EST
From:      Hans-Werner_Braun@UMich-MTS.MAILNET
To:        mod.protocols.tcp-ip
Subject:   re: X.25 Standard service on ARPANET

Yes, one of them is the operational gateway between the NSFnet and the
Arpanet, because of which I had asked the question in the first place.
Packets between the NSfnet and the Arpanet are now flowing in a more
operational sense than before, even though there are some (non-IMP
related) problems left, i.e., the IMP at PSC/CMU gets only the outgoing
packets at this point of time, while the incoming packets are still
traversing the slower DCNet/UMICH/USAN path. This will be fixed shortly,
but as said, it's not IMP or X.25 interface related. The Standard-X.25
interface appears to be behaving fine, as it's getting packets almost all
week already.

         -- Hans-Werner

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Oct-86 10:41:39 EST
From:      markl@JHEREG.LCS.MIT.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  Setting Initial Round-trip time

Don't use NETBLT.  Not yet.  NETBLT is an *experiment* in high-speed
bulk data transfer.  It works best over long-delay, high-bandwidth
(i.e. satellite) networks, although it gives very good performance on
othre networks as well.  Although a proposed spec is available, we are
actively discouraging people from implementing it until we decide
whether or not the experiment works.  We are currently testing NETBLT
over the Wideband network with fairly good results, but a lot of work
needs to be done tuning the spec before anyone can use NETBLT.

				Mark

Internet: markl@jhereg.lcs.mit.edu

MIT Laboratory for Computer Science
Distributed Systems Group

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Oct-86 13:04:19 EST
From:      braden@ISI.EDU (Bob Braden)
To:        mod.protocols.tcp-ip
Subject:   Re:  Poor performance related to egp?

The examples you cite of "horrible" EGP routing are probably due to the
extra-hop problem in the core.  Apparently we have not done an adequate
job of information-spreading, if you are not aware of this problem.  I
seem to recall a blaze of messages on this very subject within the past 6
months, probably on the tcp-ip list.  It began with a complaint almost
identical to yours, and ended with a scholarly explanation of the
extra-hop problem by Dave Mills.

The extra-hop problem can at worst double the core traffic, and it is
scheduled to go away when the Butterflies take over the core.  I forget
the exact predicted date from BBN, but rescue is in sight.

As for performance, in some funny sense EGP is (deliberately) designed for
poor performance, in the sense that it is intended to server as a firewall
against misbehaviour by routing domains outside the core.  It is true, as
Mike StJohns says, that EGP is not a routing protocol; it is also true that
this fact has led to serious restrictions in topology and therefore a
crash effort is being mounted to replace EGP with a routing protocol, under
the direction of the INENG and INARCH task forces. 
 
However, maybe we are asking too much of EGP.  Perhaps we are trying to
make it a technical fix for administrative problems.  To avoid bad things
like oscillations and routing loops in the face of the "diversity" (to
use a nice word) of the Internet as a whole, EGP or whatever replaces it
will always have to use long time constants and provide some sub-optimal
routes.  At the present time, the Internet is growing largely by
accretion of new Autonomous Systems, and this must lead to some 
degradation as you cross boundaries.  If we want better overall
performance, we need to persuade these systems to aggregate into bigger
systems, each run by centralized and professional Internet management,
and each using a carefully-optimized IGP.

I go into all this polemic, because lately I have been exposed to an 
awful lot of technological optimism (ask NASA about that!) about 
Internetting.  I wish we could convince some of the new players in the
Internet game that it takes great technical sophistication and wisdom
to make this stuff work well.  The Anarchy Model of Internetting,
while theoretically feasible due to EGP, is not really a very wise way
to go.

Bob Braden

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Oct-86 13:13:01 EST
From:      van@LBL-CSAM.ARPA (Van Jacobson)
To:        mod.protocols.tcp-ip
Subject:   Re: Setting Initial Round-trip time

I've got a little bit of hard data and a simple change that may improve
things for 4.[23]bsd.  About six months ago I instrumented our Internet
gateway to record a timestamp, src & dst address and port and data & ack
sequence numbers for each tcp packet.  I reduced two days worth of
this trace data and found

  . the distribution of number of data packets sent on a connection
    was roughly exponential with a mean of 4 (e.g., a lot of mail
    traffic).

  . between 7am and 5pm, PDT, the mean number of retransmissions per
    data packet was 8.  The distribution was bi-modal, with traffic
    through the "mail bridges" in one lobe (with a mode of ~11) and
    all other traffic in the other lobe (a mode of ~2).  Both lobes
    were approximately Poisson, possibly due to the long "learning
    time" of round trip timers on the connections.

  . For a particular connection, round trip times varied about an
    order of magnitude.  Over all connections, round trip times
    varied three orders of magnitude.  (With the large number of
    retransmissions, there is some ambiguity in which packets one
    uses to estimate RTT.  I generally used the time from the first
    use of a sequence number to its first ack, with some ad hoc
    hackery to accomodate the 50% packet loss through the mail
    bridges.  Given this ambiguity, the uncertainty in any RTT
    estimate is at least a factor of two.)

  . The next hop Internet gateway was strongly correlated with the RTT
    in the following sense:  the average RTT of all packets through a
    gateway is within a factor of three of the average RTT of each
    connection through that gateway.

It is not hard to convince yourself that no reasonable setting of the
RTT initial value & filter constants is going to accomodate a factor
of 1000 variation in four packets worth of learning time.  I mentioned
the problem to Mike O'Dell & he suggested using the kernel's routing
entry to cache the RTT.  I made up a kernel that kept an RTT in each
route.  When a TCP connection was opened, it initialized its RTT from
the route.  When the connection closed, its RTT was used to update
the route's RTT with a weighted average
     Rt = A * Rt + (1-A) * Conn
(the 4.3bsd kernel changes for all this amount to about 20 lines of C).

I took 12 hours of trace data with the filter constant set to .5.
The average number of retransmissions *for traffic that originated at
the gateway* went down a factor of two (8 to 4).  I was going to take
more data and try tuning the connection and route filter constants.
Unfortunately, some local political changes intervened and I can no
longer make changes or take data on the gateway.  However, the initial
results were promising enough that I plan to try a similar scheme
for machines that sit behind the gateway (i.e., construct pseudo-route
entries to cache the RTT).

  - Van Jacobson, LBL

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31-Oct-86 16:03:42 EST
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: Poor performance related to egp?


	I seem to explain this every 2 months.

	The problem is not caused by EGP, which is telling you exactly
what the gateway you are neighbours with is doing itself with packets
to given destinations, but the routing protocol (GGP) which is used by
the core gateways among themselves. It predates EGP, was not designed
with the pattern of information flows that you see in EGP in mind, and
is the cause of the problem. When GGP is replaced (which will probably
be when the PDP11's are) the problem will magically disappear without
any changes to EGP.

	For a more detailed explanation of the problem, look in the
TCP-IP archive for a message I sent out at Thu 6 Mar 86 18:16:01-EST
which goes into great detail. Just out of interest, were you on
TCP-IP then?

	Noel
-------

END OF DOCUMENT