The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Dec-85 18:36:42 EST
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Re:  name servers

The Berkeley BIND domain server is distributed by Kevin Dunlap,
<kjd@monet.berkeley.edu> or <kjd@berkeley.arpa>.  Contact him
for information.  It runs on 4.2 and 4.3 BSD UNIX systems.
	-Mike

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Dec 85 18:36:42 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        Nat Howard <nrh@ddnt.arpa>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  name servers
The Berkeley BIND domain server is distributed by Kevin Dunlap,
<kjd@monet.berkeley.edu> or <kjd@berkeley.arpa>.  Contact him
for information.  It runs on 4.2 and 4.3 BSD UNIX systems.
	-Mike
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Dec-85 19:19:42 EST
From:      sra@MITRE-BEDFORD.ARPA
To:        mod.protocols.tcp-ip
Subject:   Network Management Softwore

I am interested in Management software for TCP/IP LANS, especially 802
compatible LANS.

Of particular interest are

	Initializing and reconfiguring network resources from a central
	location

	Providing reports on performance and operational status

	Providing accounting information regarding the use of network services

	Detecting and resolving network operation problems

Any information concerning the availability of such software would be greatly
appreciated.

Stan Ames
sra at MITRE-BEDFORD.arpa

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Dec-85 14:04:54 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Musical routing table slots


	I thought I'd warn everyone that we are in for a spell of
musical chairs with the routing tables in the BBN core gateways
again. Apparently we are up over 120 networks in the system, which is
more networks than the core gateways have routing table slots, so if
your gateway crashes you may find yourself out in the cold when you
try and get back in. I don't know exactly when relief is coming;
I spoke to someone at BBN and they are preparing to bring out a
new release with more slots, but there's no definite timeline.
	In the interim, I appeal to all sites with more than
one network number to please convert to using subnets.

	Noel
-------

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Dec-85 01:26:59 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Space wars


	Actually, I'm a little bit puzzled by this space issue. In the
CGW, a route takes up 14 bytes while an EGP neighbour takes up about
50. Admittedly, some of the fields in the EGP block aren't use
simultaneously, and could be overlapped, but it's still not small.
What I find curious is that the core gateways will apparently happily
take many neighbours, but don't have room for routing entries. Why are
the routing entries in the BBN gateways so large? Can someone from
BBN explain what's going on here?

	Noel
-------

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Dec-85 16:35:32 EST
From:      brescia@BBNCCV.ARPA (Mike Brescia)
To:        mod.protocols.tcp-ip
Subject:   Re: Space wars


The BBN gateways current version does not use memory mapping in the lsi11.
(There are even some of the machines which are 11/02 without mapping hardware.)
The tradeoff in memory is between packet buffers and routing table entries.
Currently, the buffer capacity at some sites is just enough to absorb a bunch
of packets from an ethernet (fast) sending out to an arpanet (slow) for a
single ftp connection.  In those cases, losing one buffer causes the
probability of packet dropping to increase dramatically.  Just ask the people
at ISI.

Memory mapping is included in a new version of software which is now running
on a machine between bbnnet and arpanet and a local ethernet (which is to say
that it is beyond debugging and into testing).  In a couple of weeks, it
should be released to some sites which have memory mapping hardware (11/23
processors).  The arpanet-milnet gateways are being placed under configuration
management, and should be ready for release with memory mapping in a couple of
months.

Memory mapping will allow extra memory to be used for buffering and allow more
networks to be listed.

	Mike Brescia

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      04 Dec 85 16:35:32 EST (Wed)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        egp-people@BBNCCV.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re: Space wars

The BBN gateways current version does not use memory mapping in the lsi11.
(There are even some of the machines which are 11/02 without mapping hardware.)
The tradeoff in memory is between packet buffers and routing table entries.
Currently, the buffer capacity at some sites is just enough to absorb a bunch
of packets from an ethernet (fast) sending out to an arpanet (slow) for a
single ftp connection.  In those cases, losing one buffer causes the
probability of packet dropping to increase dramatically.  Just ask the people
at ISI.

Memory mapping is included in a new version of software which is now running
on a machine between bbnnet and arpanet and a local ethernet (which is to say
that it is beyond debugging and into testing).  In a couple of weeks, it
should be released to some sites which have memory mapping hardware (11/23
processors).  The arpanet-milnet gateways are being placed under configuration
management, and should be ready for release with memory mapping in a couple of
months.

Memory mapping will allow extra memory to be used for buffering and allow more
networks to be listed.

	Mike Brescia
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 1985 19:44:07 PST
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        Mike Brescia <brescia@BBNCCV.ARPA>
Cc:        egp-people@BBNCCV.ARPA, tcp-ip@SRI-NIC.ARPA, LYNCH@USC-ISIB.ARPA
Subject:   Re: Space wars
When I saw the first message on this topic I thought the issue was
one of an outdated algorithm for routing table maintenance and not
one of just increasing the table size to get over the current hump.
Since some of the gateways will never have much memory (when is there
ever "enough"?) it would appear that a name server model for 
gateways is in order.  Hosts already have to deal with this issue
(if they are playing it "honestly").
Dan
-------
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Dec-85 22:44:07 EST
From:      LYNCH@USC-ISIB.ARPA (Dan Lynch)
To:        mod.protocols.tcp-ip
Subject:   Re: Space wars

When I saw the first message on this topic I thought the issue was
one of an outdated algorithm for routing table maintenance and not
one of just increasing the table size to get over the current hump.
Since some of the gateways will never have much memory (when is there
ever "enough"?) it would appear that a name server model for 
gateways is in order.  Hosts already have to deal with this issue
(if they are playing it "honestly").
Dan
-------

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Dec-85 01:59:33 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Space wars

In response to the message sent  04 Dec 85 16:35:32 EST (Wed) from brescia@BBNCCV.ARPA

Mike,

While more memory might provide a few more nets, my comment on packet-size
limitations presumably remains valid. Last we talked, I think something
like 130-odd networks was expected to break, depending upon the exact mix
of class A/B/C nets. I got a taste today myself, when our beloved gateway
winced and we had to recompete the table entries. Do not bury the
port-expander nets just yet...

Dave
-------

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Dec-85 08:43:56 EST
From:      sra@MITRE-BEDFORD.ARPA
To:        mod.protocols.tcp-ip
Subject:   Network Security

I would like to start a dialogue on network security.

We currently have one host on the Milnet and are about to hook up 
our Ethernet subnet through a gateway.  The problem is that upper 
level management is deathly afraid of hackers rummaging around 
throughout our network.

It seems that one host on the network is almost acceptable but 
many may open up Pandoras box.

What types of controls could be placed within the gateway to 
limit our access to random telnets and what arguments could we 
use to convince management that connecting our subnet to the 
Milnet does not increase our exposure to random attacks.

Stan Ames
sra at MITRE-Bedford

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Dec-85 09:47:01 EST
From:      PADLIPSKY@USC-ISI.ARPA
To:        mod.protocols.tcp-ip
Subject:   Creative Typo (?)


I imagine Dave meant "recompute" (or even maybe "recomplete")
rather than "recompete" the table entries, but if not, does this
mean he's already doing something along the lines of Dan's suggested
name server trick (by letting the available entry slots get filled
in dynamically--and hence "competing" for them)?

cheers, map
-------

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 85 15:11:00 PST
From:      <gary@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   performance using IBM front-ends

ACC would be interested in knowing some perfromance figures for
the various IBM front-end systems currently installed.  Of particular
interest would be end-to-end sustained data rates between two hosts.
That and various implemention considerations would also be useful.

So as not to clutter the network please address your responses to me
and I will summarize for the community.

Regards,

Gary Krall
------
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Dec-85 12:12:57 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Creative Typo (?)

In response to the message sent   5 Dec 1985 09:47:01 EST from PADLIPSKY@USC-ISI.ARPA

Mike,

My choice of word was deliberate and, I believe, accurate.

I have had to take drastic action here, since congestion has sometimes
toppled our gateway and broken EGP connectivity. Specifically, I intend
to limit the number of nets per site in our backlot to one. I expect that
may precipitate a headlong dash for 4.3bsd for its subnet code. Apollo and
Sun, please take note.

Dave
-------

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Dec-85 13:09:48 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: Network Security


	Various potential users of C Gateways have requested similar
capabilities, and we had set up a mailing list to discuss exactly what
mechanisms would be useful. However, due to lack of time on my part
nothing has happened there yet. I would caution that the TCP-IP mailing
list is a little big to conduct a discussion on; unfortunately I
don't know of a good substitute.
	I would suggest that you contact your gateway vendor and see
if he has any plans, or is setting up a customer discussion group. If
you built your own gateway, then you're out in the cold; as far as I
know, nobody has built any fancy access control mechanisms into
any gateways yet. I'm not sure I see any necessity for standardization
here; creating standards takes energy, of which there is a limited
amount, and there are more important things needing to be standardized.

	Noel
-------

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Dec-85 17:21:44 EST
From:      OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen)
To:        mod.protocols.tcp-ip
Subject:   My Christmas Wish


Hi folks,
		I am doing my best to keep the entries in the TCP/IP
Vendor's Guide as up-to-date as possible. If you know of any information
which is either missing, wrong, out-of-date and so on, please let me
know so that we can make this document as useful as possible. The most
recent version is always kept in:

	[SRI-NIC.ARPA]TCP-IP-IMPLEMENTATIONS.TXT

		We are planning to produce hard copy versions every
6 months starting in January 1986.

Cheers,
	<OLE>
	<370>
-------

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Dec-85 17:58:11 EST
From:      OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen)
To:        mod.protocols.tcp-ip
Subject:   OOOOOOPS!!!


Forgot to give you the directory name, <NETINFO> so that line should
read:

	[SRI-NIC.ARPA]<NETINFO>TCP-IP-IMPLEMENTATIONS.TXT

Sorry!

	Ole
-------

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Dec-85 18:11:00 EST
From:      gary@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   performance using IBM front-ends


ACC would be interested in knowing some perfromance figures for
the various IBM front-end systems currently installed.  Of particular
interest would be end-to-end sustained data rates between two hosts.
That and various implemention considerations would also be useful.

So as not to clutter the network please address your responses to me
and I will summarize for the community.

Regards,

Gary Krall
------

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Dec-85 19:09:56 EST
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Re:  Network Security

If any of your hosts have dialups, then they are not any worse off being
gatewayed to the MILNET.

In any case, you can't depend on the network to provide reasonable
security -- responsibility for security rests firmly on the host machine.
For Army machines, this policy is well articulated by AR 380-380.

BRL's machines implement minimum 6 char passwords, logging of all
login attempts, both good and bad, plus operator notification of
EVERY bad login attempt, plus connection disconnect after 3 tries.

We have found these measures to adequately protect our machines at BRL.
	-Mike

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Dec 85 19:09:56 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        sra@mitre-bedford.arpa
Cc:        egp-people@bbnccv.arpa, tcp-ip@sri-nic.arpa, sra@mitre-bedford.arpa
Subject:   Re:  Network Security
If any of your hosts have dialups, then they are not any worse off being
gatewayed to the MILNET.

In any case, you can't depend on the network to provide reasonable
security -- responsibility for security rests firmly on the host machine.
For Army machines, this policy is well articulated by AR 380-380.

BRL's machines implement minimum 6 char passwords, logging of all
login attempts, both good and bad, plus operator notification of
EVERY bad login attempt, plus connection disconnect after 3 tries.

We have found these measures to adequately protect our machines at BRL.
	-Mike
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Dec-85 09:04:32 EST
From:      steve@APLVAX.ARPA (Steven Kahn)
To:        mod.protocols.tcp-ip
Subject:   TCP-IP mailing list


Could you please put me on the TCP-IP mailing list.
Also, I understand that you maintain a file of
previous correspondence. How could I obtain such
a file, particular correspondence dealing with
4.2BSD UNIX issues?

Thanks very much,

	Steve Kahn
	Johns Hopkins U. Applied Physics Lab
	Laurel, MD 20707
	(312) 953-6812

	Milnet:  steve@aplvax.arpa

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Dec-85 10:23:28 EST
From:      PADLIPSKY@USC-ISI.ARPA
To:        mod.protocols.tcp-ip
Subject:   Slot Mechanics

Hmmm.  I don't know about you, but I saw Dave Mills' answer
to my comment on his non-typo before the comment came out in the
Digest.  There must be something funny about competing for slots
here, too.

Since he did really mean "recompeting", the Conditions of Contest
would presumably be of interest to others than myself and Dan
Lynch.  How about it, David?  What DO you mean by "recompeting"?
(Don't need/want a Documentation Algol version of the algorithm
[unless that's the easiest thing for you to do], but more than
the cryptic-to-me reference to one net per site in the backlot
would be most helpful.)

cheers, map
-------

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Dec-85 10:39:49 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Moderated newsgroup

This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10.2 9/17/84; site mhuxh.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: mhuxh!mhuxv!mhuxt!mhuxr!ulysses!cbosgd!ucbvax!tcp-ip
From: mike@BRL.ARPA (Mike Muuss)
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Network Security
Message-ID: <8512060224.AA16360@ucbvax.berkeley.edu>
Date: 6 Dec 85 00:09:56 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 17

Organization; The ARPA Internet
Lines: 13
Approved: tcp-ip@sri-nic.arpa

If any of your hosts have dialups, then they are not any worse off being
gatewayed to the MILNET.

In any case, you can't depend on the network to provide reasonable
security -- responsibility for security rests firmly on the host machine.
For Army machines, this policy is well articulated by AR 380-380.

BRL's machines implement minimum 6 char passwords, logging of all
login attempts, both good and bad, plus operator notification of
EVERY bad login attempt, plus connection disconnect after 3 tries.

We have found these measures to adequately protect our machines at BRL.
	-Mike

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Dec-85 12:52:05 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Slot Mechanics

In response to the message sent   6 Dec 1985 10:23:28 EST from PADLIPSKY@USC-ISI.ARPA

cheers,

Our gateway has several customers scattered from Maryland to California,
all of which have extensive subnet networks in order to reduce the demand
for core slots. One of our customers is using a class-C number because
his Apollos cannot the subnet thing do. My comment was to suggest to him
those Apollos either learn that trick or go babble only with themselves.

There is nothing mysterious about competing for slots. All slots are normally
occupied, so a new player must wait for an old gateway to crash, then grab
a slot before anyone else can. Exactly like hunting for parking spaces during
the Christmas rush. An agressive new player can always send a kiss-of-death
packet to another gateway to increase the odds, of course. I will not describe
what a kod packet is or might be.

Dave
-------

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Dec-85 18:28:22 EST
From:      martin%blade@MOUTON.ARPA (Martin J Levy)
To:        mod.protocols.tcp-ip
Subject:   Re: Slot Mechanics

people may be interested to note that when Bell Communications Research
Joined CSNET and also got connectivity to the ARPANET, we asked that
our ~23 Class C networks be added to the Core Gateways routing tables.

you can guess the reply we got. hence work underway to convert too a 
class B subnet scheme.

martin levy
stuck on one of those non connected networks.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Dec-85 13:11:00 EST
From:      DCP@SCRC-QUABBIN.ARPA (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   Zero window probes

(Sorry for the slow comment, I've been off the net for a month.)  I
agree with the philosophical basis as stated by CERF.  TCP allows the
sending of one byte beyond the window for the purposes of probing.
Since the byte is outside the window, the receiver MUST send an ACK.
This shows that both TCP's are alive, and it is up to the higher level
protocols to decide that the connection is worthless, even though the
connection still validly exists.  Therefore, I believe TOPS-20 and Unix
(whichever version somebody mentioned) are in error by having TCP do the
timeout.

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Dec-85 05:49:00 EST
From:      Vshank@WEIZMANN.BITNET (Henry Nussbacher)
To:        mod.protocols.tcp-ip
Subject:   Tim Fallon

I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors
Guide lists him as timf%tek@rand-relay.arpa.  I tried
timf%tektronix@csnet-relay.arpa but that didn't help.  Can someone please
send me his network address (I am trying to track down the VMS Tcp/Ip
program distributed by Tektronix).

Sorry for bothering the list,
Hank

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Dec 1985 12:49 O
From:      Henry Nussbacher  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
To:        <tcp-ip@sri-nic.ARPA>
Subject:   Tim Fallon
I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors
Guide lists him as timf%tek@rand-relay.arpa.  I tried
timf%tektronix@csnet-relay.arpa but that didn't help.  Can someone please
send me his network address (I am trying to track down the VMS Tcp/Ip
program distributed by Tektronix).

Sorry for bothering the list,
Hank
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Dec-85 11:49:35 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Spartacus Knet and Wisconsin Wiscnet

How about Spartacus Knet and IBM VM support for TCP/IP (basically Wiscnet)?

Tom Webb

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Dec-85 21:08:43 EST
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Gateway Slots

Sirs -

I am writing this letter to bring to your attention a serious operational
problem with the CORE gateway system which provides routing connectivity
between the ARPANET, MILNET, SATNET, and all LANs within the InterNet system.
Briefly stated, the problem is that the current core gateway software only
has room for a fixed number of routes between networks, currently about 100.
(I'll call these routing table entries "slots").

Within the past few weeks, the number of networks (mostly LANs)
connected to the InterNet system has exceeded the number of slots,
resulting in a shortage of slots.  Attempts to provide routing information
to the core system are processed only as slots become available -- on a
first-come, first-served basis.  Some gateway somewhere has to crash to
relinquish a slot for another gateway to gain connectivity.

MAJOR FAILURE IN OPERATIONAL SYSTEM.

This past weekend, due to an extensive power outage, both of BRL's gateways
were down, relinquishing the slots we had been using.  BRL's IMP resumed
operating Sunday night, and BRL's 2 Gateways resumed operation Monday
morning, but BRL was completely without network connectivity throughout the
day Monday as we waited for slots to become available within the core
gateway system.  Lack of slots prevented any access to or from the MILNET,
blocking mail flow between BRL and AMC-HQ, USNA, ARDC, WSMR, and the
numerous other hosts we do regular business with.  Fortunately, other
gateways went down through the day, and by Monday evening BRL had reacquired
routing slots.  A one-day network outage was no disaster, and we survived.
However, if we loose network connectivity for a day or more every time our
gateways or IMP go down, BRL has a major operational problem.

Unless corrective action is taken, this problem will steadily become worse,
because more and more MILNET sites will be operating attached LANs, and
traffic is shifting from directly attached hosts to LAN-attached hosts.  BRL
feels the effect of this problem more keenly because BRL hosts are
exclusively LAN-attached.  However, all LAN-attached hosts within the
InterNet system are affected by this problem!

This problem was also encountered a few months ago, and BBN responded
promptly by increasing the number of slots to the current limit.  BBN
is aware of the current problem, and is investigating solutions.  However,
they may not be able to increase the table sizes this time, due to limited
memory in the core gateways.  The medium-term solution to this problem
would be to replace all LSI-11/03 core gateways with LSI-11/23 gateways,
which have 4 times as much memory.  I am under the impression that BBN
has already developed software which takes advantage of the extra memory
in the 11/23.  The long-term solution is, of course, to replace the core
gateway system with Butterfly gateways, but that is a long time away.

SHORT-TERM SOLUTION NEEDED.

There are several options.

1)  Take administrative action.  Insist that the most recent N new
networks connected to the InterNet system immediately disconnect, until
the number of available slots can be increased.

2)  Provide a technological response.  Instituting emergency measures,
rapidly replace the core gateway system with 11/23 systems. 

2a)  Have BBN immediately upgrade all 11/03 systems withing the GGP core.
2b)  If BBN does not have necessary equipment on hand, or en route,
additional 11/23 system could be borrowed.  For example, BRL has an 11/23
system which is temporarily not being used.  BRL would be willing to loan it
to DCA on a short term basis until BBN could procure the necessary 11/23
hardware.  Certainly there are enough unused 11/23 systems throughout the
combined Services that an immediate hardware solution could be implemented
using loaned equipment.

3) Apply software magic, and increase the current table size without
changing any hardware.  This may be easy, but more likely it will be costly
in time, costly in manpower, or simply impossible.

MEDIUM-TERM DISASTER AWAITS.

Even assuming that the current difficulty can be overcome, this problem will
reappear again soon in another form.  Indeed, the second stage of this
problem is almost upon us.  Here, the difficulty is again a growth limitation in
the core gateway software.  The core exchanges routing information between
it's gateways using GGP (Gateway-to-Gateway Protocol).  There exists an upper
limit on the length of a GGP packet, and GGP is currently defined so as to
contain information about the total InterNet system in a single packet.
Thus, when the number of gateways increases beyond the number that can fit
in a GGP packet, we will again experience competition for "slots" -- this
time GGP packet "slots".

Again, several solutions exist:

1)  Administratively prohibit connecting more LANs than the GGP protocol
can support.

2)  Modify or extend the GGP protocol and the supporting core gateway
software to ease or eliminate the current limits.

3)  Replace the GGP protocol with something else (no finished design for
a replacement exists yet, although it is being thought about).

3a)  Replace GGP within the existing 11/23 systems with the new protocol.
3b)  Replace all the 11/23 systems with Butterfly systems and the new
protocol.

Current plans for GGP replacement are being formed within BBN and the GADS
Task Force (chaired by the able Dave Mills).  I would like to suggest that
the priority of this task be elevated, and that it's funding be increased.
Investing in an extra man-year now might give us a long-term solution to
this problem before disaster strikes.  (I might also point out that the GADS
Task Force is presently operating with little or no funding).  Either GADS
or BBN must get switched into "high gear" to solve this problem.

SUMMARY.

The "lack of slots" problem is upon us.  Serious operational failures have
already been experienced, and the problem will be getting worse.  A short
term solution is needed.  Several options are available, none expensive.

Worse, a secondary form of the problem will strike soon, even if we weather
the current storm.  Solutions can be found, but all will require effort and
money.  Spending money takes time, so we need to worry now.

	Sincerely,

	 Mike Muuss
	 Leader, Advanced Computer Systems Team
	 U. S. Army Ballistic Research Lab

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Dec 85 21:08:43 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        Col Maybaum <lmaybaum@ddn1.arpa>, Baker@isi.arpa
Cc:        TCP-IP@sri-nic.arpa, Bloom@monet.berkeley.edu, dca-pgs@ddn1.arpa
Subject:   Gateway Slots
Sirs -

I am writing this letter to bring to your attention a serious operational
problem with the CORE gateway system which provides routing connectivity
between the ARPANET, MILNET, SATNET, and all LANs within the InterNet system.
Briefly stated, the problem is that the current core gateway software only
has room for a fixed number of routes between networks, currently about 100.
(I'll call these routing table entries "slots").

Within the past few weeks, the number of networks (mostly LANs)
connected to the InterNet system has exceeded the number of slots,
resulting in a shortage of slots.  Attempts to provide routing information
to the core system are processed only as slots become available -- on a
first-come, first-served basis.  Some gateway somewhere has to crash to
relinquish a slot for another gateway to gain connectivity.

MAJOR FAILURE IN OPERATIONAL SYSTEM.

This past weekend, due to an extensive power outage, both of BRL's gateways
were down, relinquishing the slots we had been using.  BRL's IMP resumed
operating Sunday night, and BRL's 2 Gateways resumed operation Monday
morning, but BRL was completely without network connectivity throughout the
day Monday as we waited for slots to become available within the core
gateway system.  Lack of slots prevented any access to or from the MILNET,
blocking mail flow between BRL and AMC-HQ, USNA, ARDC, WSMR, and the
numerous other hosts we do regular business with.  Fortunately, other
gateways went down through the day, and by Monday evening BRL had reacquired
routing slots.  A one-day network outage was no disaster, and we survived.
However, if we loose network connectivity for a day or more every time our
gateways or IMP go down, BRL has a major operational problem.

Unless corrective action is taken, this problem will steadily become worse,
because more and more MILNET sites will be operating attached LANs, and
traffic is shifting from directly attached hosts to LAN-attached hosts.  BRL
feels the effect of this problem more keenly because BRL hosts are
exclusively LAN-attached.  However, all LAN-attached hosts within the
InterNet system are affected by this problem!

This problem was also encountered a few months ago, and BBN responded
promptly by increasing the number of slots to the current limit.  BBN
is aware of the current problem, and is investigating solutions.  However,
they may not be able to increase the table sizes this time, due to limited
memory in the core gateways.  The medium-term solution to this problem
would be to replace all LSI-11/03 core gateways with LSI-11/23 gateways,
which have 4 times as much memory.  I am under the impression that BBN
has already developed software which takes advantage of the extra memory
in the 11/23.  The long-term solution is, of course, to replace the core
gateway system with Butterfly gateways, but that is a long time away.

SHORT-TERM SOLUTION NEEDED.

There are several options.

1)  Take administrative action.  Insist that the most recent N new
networks connected to the InterNet system immediately disconnect, until
the number of available slots can be increased.

2)  Provide a technological response.  Instituting emergency measures,
rapidly replace the core gateway system with 11/23 systems. 

2a)  Have BBN immediately upgrade all 11/03 systems withing the GGP core.
2b)  If BBN does not have necessary equipment on hand, or en route,
additional 11/23 system could be borrowed.  For example, BRL has an 11/23
system which is temporarily not being used.  BRL would be willing to loan it
to DCA on a short term basis until BBN could procure the necessary 11/23
hardware.  Certainly there are enough unused 11/23 systems throughout the
combined Services that an immediate hardware solution could be implemented
using loaned equipment.

3) Apply software magic, and increase the current table size without
changing any hardware.  This may be easy, but more likely it will be costly
in time, costly in manpower, or simply impossible.

MEDIUM-TERM DISASTER AWAITS.

Even assuming that the current difficulty can be overcome, this problem will
reappear again soon in another form.  Indeed, the second stage of this
problem is almost upon us.  Here, the difficulty is again a growth limitation in
the core gateway software.  The core exchanges routing information between
it's gateways using GGP (Gateway-to-Gateway Protocol).  There exists an upper
limit on the length of a GGP packet, and GGP is currently defined so as to
contain information about the total InterNet system in a single packet.
Thus, when the number of gateways increases beyond the number that can fit
in a GGP packet, we will again experience competition for "slots" -- this
time GGP packet "slots".

Again, several solutions exist:

1)  Administratively prohibit connecting more LANs than the GGP protocol
can support.

2)  Modify or extend the GGP protocol and the supporting core gateway
software to ease or eliminate the current limits.

3)  Replace the GGP protocol with something else (no finished design for
a replacement exists yet, although it is being thought about).

3a)  Replace GGP within the existing 11/23 systems with the new protocol.
3b)  Replace all the 11/23 systems with Butterfly systems and the new
protocol.

Current plans for GGP replacement are being formed within BBN and the GADS
Task Force (chaired by the able Dave Mills).  I would like to suggest that
the priority of this task be elevated, and that it's funding be increased.
Investing in an extra man-year now might give us a long-term solution to
this problem before disaster strikes.  (I might also point out that the GADS
Task Force is presently operating with little or no funding).  Either GADS
or BBN must get switched into "high gear" to solve this problem.

SUMMARY.

The "lack of slots" problem is upon us.  Serious operational failures have
already been experienced, and the problem will be getting worse.  A short
term solution is needed.  Several options are available, none expensive.

Worse, a secondary form of the problem will strike soon, even if we weather
the current storm.  Solutions can be found, but all will require effort and
money.  Spending money takes time, so we need to worry now.

	Sincerely,

	 Mike Muuss
	 Leader, Advanced Computer Systems Team
	 U. S. Army Ballistic Research Lab
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 12 Dec 85 11:11:39 PST
From:      Jeff Mulick <jeffm%tektronix.csnet@CSNET-RELAY.ARPA>
To:        ucbvax!tcp-ip%tektronix.csnet@CSNET-RELAY.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Tim Fallon
< >

Tim Fallon is no longer with Tektronix, and I have replaced him. Requests for
the tcp/ip VMS software should be sent to jeffm%tektronix@csnet-relay.arpa

Thanks,

Jeff Mulick
Computer Resource Department   DS 50/454
Tektronix, Inc.
P.O. Box 500
Beaverton, OR  97077

UUCP:		...decvax!tektronix!jeffm
ARPA:		jeffm%tektronix@csnet-relay.arpa
CSnet:		jeffm@tektronix.csnet
MaBell:		(503) 627-5007
------------------------------------------------
In reference to :

Article 116 of mod.protocols.tcp-ip:
Relay-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tektronix.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: tektronix!uw-beaver!cornell!vax135!houxm!mhuxt!mhuxr!ulysses!cbosgd!ucbvax!tcp-ip
>From: Vshank@WEIZMANN.BITNET (Henry Nussbacher)
Newsgroups: mod.protocols.tcp-ip
Subject: Tim Fallon
Message-ID: <8512101110.AA12546@ucbvax.berkeley.edu>
Date: 10 Dec 85 10:49:00 GMT
Date-Received: 12 Dec 85 02:24:17 GMT
Sender: kennish@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 8
Approved: tcp-ip@sri-nic.arpa

I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors
Guide lists him as timf%tek@rand-relay.arpa.  I tried
timf%tektronix@csnet-relay.arpa but that didn't help.  Can someone please
send me his network address (I am trying to track down the VMS Tcp/Ip
program distributed by Tektronix).

Sorry for bothering the list,
Hank

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 1985 13:12:49 PST
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        MILLS@USC-ISID.ARPA
Cc:        mike@BRL.ARPA, lmaybaum@DDN1.ARPA, tcp-ip@SRI-NIC.ARPA, Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA, gateway-tf@USC-ISIB.ARPA, lynch@USC-ISIB.ARPA
Subject:   Subnetting and gateways
Dave,  Your last line was a whopper:  that new procurements have
subnetting support written into them!  That is a rathr drastic
measure and only pushes off the day when gateways will have to
get smart anyway.  I would vote for putting the most intelligence
(and hairy algorithms) in the fewest possible places.  That says to
make gateways smart and let the hosts play dumb.  Let there
be a big database in the sky somewhere (known only to gateways?) that
knows all routes and connectivity gory details.  Then the gateways
should just act as a cache for that monster database and feed their
clients (hosts) info on a demand basis.  
This principle harkens from the days of early radio design when
someone called a halt to the (then) impending decision to make
the "protocol" between transmitters and receivers well "balanced" by spreading
the implementation costs equally.  The observation was made that
when things got going hot and heavy there would be millions of receivers
and only thousands of transmitters, so put the hair in the transmitters
and make the receivers as simple as possible.  (I am indebted to
Dave Boggs for this story.)  So, I argue for making life as simple
as possbile for the multitude of hosts and put the hair in the 
gateways.

Dan
-------
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 1985 1511-PST (Thursday)
From:      Jeff Mogul <mogul@su-navajo.arpa>
To:        Dan Lynch <LYNCH@USC-ISIB.ARPA>
Cc:        mike@BRL.ARPA, lmaybaum@DDN1.ARPA, tcp-ip@SRI-NIC.ARPA, Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA, gateway-tf@USC-ISIB.ARPA
Subject:   Re: Subnetting and gateways
I disagree that requiring RFC950-style subnet support is a bad
idea.  If implemented reasonably, using address masks, it
insulates a host entirely from the addressing format (i.e.,
subnets? and if so, what bits specify the subnet?)  So, rather
than moving the smarts into the hosts, RFC950 goes in the
opposite direction - put a simple mechanism into each host that
allows it to offload all the smarts onto the gateways.

Of course, even this much change is probably too much for some
of our vendors.  But the internet is too big to pretend that
subnets are unnecessary.

-Jeff

P.S.: I believe Noel Chiappa has consistently advocated the position
that non-gateway hosts should not even have routing tables;
just a large enough redirect table (with host redirects only)
and the address of one or more neighbor gateways.
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Dec-85 12:41:53 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   (none)

Folks,

The issue is prominent on the agenda for the next GADS meeting on 16-17
January.

It should be emphasized that immediate short-term relief can also result from
an agressive campaign to use subnets, as described in RFC940 and RFC950.
Subnets allow the internal structure of large communities of LANs, such as in
use at MIT, CMU, Stanford and here, to be hidden from the Internet system at
large. However, not all software implementations support a subnet feature, in
particular Berkeley Unix 4.2bsd ex box.

It would obviously be to great advantage either to retrofit subnet code in the
4.2bsd systems or to upgrade to 4.3bsd, which has that code. However, in the
case of some popular workstations, including Sun and Apollo, this is not
possible without the manufacturer's committment and support. Casual inspection
of the gateway tables reveals several instances where a gateway to a LAN
community lists a single class-B network together with up to several class-C
networks, lending weight to the conjecture that the primary reason for the
proliferation in class-C networks is to support just those workstations.

I conclude that an effective way to manage at least the short-term problem is
to actively encourage the upgrade of LAN software to support subnets. It
should be possible to do this via the various user groups in response to
administrative directives. I also conclude support for subnets be written into
any new procurements.

Dave
-------

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 1985 12:41:53 EST
From:      MILLS@USC-ISID.ARPA
To:        mike@BRL.ARPA, lmaybaum@DDN1.ARPA, TCP-IP@SRI-NIC.ARPA, Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA, MILLS@USC-ISID.ARPA, gateway-tf@USC-ISIB.ARPA
Cc:        Re: ;, 11 Dec 85 21: ;, 08: ;
Folks,

The issue is prominent on the agenda for the next GADS meeting on 16-17
January.

It should be emphasized that immediate short-term relief can also result from
an agressive campaign to use subnets, as described in RFC940 and RFC950.
Subnets allow the internal structure of large communities of LANs, such as in
use at MIT, CMU, Stanford and here, to be hidden from the Internet system at
large. However, not all software implementations support a subnet feature, in
particular Berkeley Unix 4.2bsd ex box.

It would obviously be to great advantage either to retrofit subnet code in the
4.2bsd systems or to upgrade to 4.3bsd, which has that code. However, in the
case of some popular workstations, including Sun and Apollo, this is not
possible without the manufacturer's committment and support. Casual inspection
of the gateway tables reveals several instances where a gateway to a LAN
community lists a single class-B network together with up to several class-C
networks, lending weight to the conjecture that the primary reason for the
proliferation in class-C networks is to support just those workstations.

I conclude that an effective way to manage at least the short-term problem is
to actively encourage the upgrade of LAN software to support subnets. It
should be possible to do this via the various user groups in response to
administrative directives. I also conclude support for subnets be written into
any new procurements.

Dave
-------
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Dec-85 12:58:32 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   (none)


	Don't forget that as a temporary measure, subnets which are
Ethernets can use the 'ARP subnet' strategy, which does not need any
changes to host software. That approach is in use both at MIT and
Stanford to support hosts which don't support subnets in our subnetted
environment.
	Noel
-------

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Dec-85 14:11:39 EST
From:      jeffm@TEKTRONIX.CSNET (Jeff Mulick)
To:        mod.protocols.tcp-ip
Subject:   Re: Tim Fallon

< >

Tim Fallon is no longer with Tektronix, and I have replaced him. Requests for
the tcp/ip VMS software should be sent to jeffm%tektronix@csnet-relay.arpa

Thanks,

Jeff Mulick
Computer Resource Department   DS 50/454
Tektronix, Inc.
P.O. Box 500
Beaverton, OR  97077

UUCP:		...decvax!tektronix!jeffm
ARPA:		jeffm%tektronix@csnet-relay.arpa
CSnet:		jeffm@tektronix.csnet
MaBell:		(503) 627-5007
------------------------------------------------
In reference to :

Article 116 of mod.protocols.tcp-ip:
Relay-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tektronix.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: tektronix!uw-beaver!cornell!vax135!houxm!mhuxt!mhuxr!ulysses!cbosgd!ucbvax!tcp-ip
>From: Vshank@WEIZMANN.BITNET (Henry Nussbacher)
Newsgroups: mod.protocols.tcp-ip
Subject: Tim Fallon
Message-ID: <8512101110.AA12546@ucbvax.berkeley.edu>
Date: 10 Dec 85 10:49:00 GMT
Date-Received: 12 Dec 85 02:24:17 GMT
Sender: kennish@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 8
Approved: tcp-ip@sri-nic.arpa

I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors
Guide lists him as timf%tek@rand-relay.arpa.  I tried
timf%tektronix@csnet-relay.arpa but that didn't help.  Can someone please
send me his network address (I am trying to track down the VMS Tcp/Ip
program distributed by Tektronix).

Sorry for bothering the list,
Hank

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Dec-85 16:12:49 EST
From:      LYNCH@USC-ISIB.ARPA (Dan Lynch)
To:        mod.protocols.tcp-ip
Subject:   Subnetting and gateways

Dave,  Your last line was a whopper:  that new procurements have
subnetting support written into them!  That is a rathr drastic
measure and only pushes off the day when gateways will have to
get smart anyway.  I would vote for putting the most intelligence
(and hairy algorithms) in the fewest possible places.  That says to
make gateways smart and let the hosts play dumb.  Let there
be a big database in the sky somewhere (known only to gateways?) that
knows all routes and connectivity gory details.  Then the gateways
should just act as a cache for that monster database and feed their
clients (hosts) info on a demand basis.  
This principle harkens from the days of early radio design when
someone called a halt to the (then) impending decision to make
the "protocol" between transmitters and receivers well "balanced" by spreading
the implementation costs equally.  The observation was made that
when things got going hot and heavy there would be millions of receivers
and only thousands of transmitters, so put the hair in the transmitters
and make the receivers as simple as possible.  (I am indebted to
Dave Boggs for this story.)  So, I argue for making life as simple
as possbile for the multitude of hosts and put the hair in the 
gateways.

Dan
-------

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Dec-85 17:15:58 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Subnetting and gateways

In response to your message sent  12 Dec 1985 13:12:49 PST

Dan,

I've never heard of Dave Bogg's story, but it probably would not apply to
the non-consumer radio community today anyway.

I'm not sure I understand what the gateways can do to ameliorate the
the problem that (some) hosts do not understand subnets, other than in the
special, but common, case of Ethernets, where Noel's suggestion might in fact be
incorporated in the present gateways without too much trouble. His technique,
which I have called "promiscuous ARP" is used in our gateways as well.

As for advanced models, you may wish to see the document NEWMOD.DOC in the MILLS
directory on ISID, which describes one possible scenario supporting mobile hosts,
multiple-destination, multiple-path routing and serves ice cream for dessert.

I suggest further discussion on this topic be switched to the tcp-ip repeater
or direct.

Dave
-------

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Dec-85 17:28:01 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tim Fallon

In article <8512101110.AA12546@ucbvax.berkeley.edu> you write:
>I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors
>Guide lists him as timf%tek@rand-relay.arpa.  I tried
>timf%tektronix@csnet-relay.arpa but that didn't help.  Can someone please
>send me his network address (I am trying to track down the VMS Tcp/Ip
>program distributed by Tektronix).
>
>Sorry for bothering the list,
>Hank

Tim Fallon has left Tektronix. Noelan Olson is the person at Tek who knows
most about the VMS TCP/IP implementation, but you have to catch him
before he leaves Tek on 12/20 - he is following Tim to a new job.

I don't know if Noelan is on the UNIX network. You can call him
at (503) 627-5278. Jeff Thomson, a fellow in Noelan's group, is available
at tektronix!tnet.

Please do not post these names and phone numbers on the net unless
Noelan or Jeff say it is okay.

	Linda Todd

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Dec-85 18:11:00 EST
From:      mogul@SU-NAVAJO.ARPA (Jeff Mogul)
To:        mod.protocols.tcp-ip
Subject:   Re: Subnetting and gateways

I disagree that requiring RFC950-style subnet support is a bad
idea.  If implemented reasonably, using address masks, it
insulates a host entirely from the addressing format (i.e.,
subnets? and if so, what bits specify the subnet?)  So, rather
than moving the smarts into the hosts, RFC950 goes in the
opposite direction - put a simple mechanism into each host that
allows it to offload all the smarts onto the gateways.

Of course, even this much change is probably too much for some
of our vendors.  But the internet is too big to pretend that
subnets are unnecessary.

-Jeff

P.S.: I believe Noel Chiappa has consistently advocated the position
that non-gateway hosts should not even have routing tables;
just a large enough redirect table (with host redirects only)
and the address of one or more neighbor gateways.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Dec-85 23:49:10 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: Subnetting and gateways


	Dan, the suggested modification to the host IP layer (to support
subnetting), and other changes in gateways that the Gateway Committee
are contemplating, are supposed to make the host IP layer simpler, not
more complicated. The whole idea is precisely to put all the smarts in
the gateway, with only the simplest possible cache in the host, and to
attempt insulate the host IP layers from any further changes to the
basic system architecture. Once all hosts use the mask technique, and
get (and use) only per-host Redirects, it will be possible for the
gateways to play arbitrary games with the layout of the system without
the host IP layers noticing. The sooner this change is installed
everywhere the better.


	Noel
-------

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Fri 13 Dec 85 09:35:33-PST
From:      Mathis@SRI-KL.ARPA
To:        MILLS@USC-ISID.ARPA
Cc:        mike@BRL.ARPA, lmaybaum@DDN1.ARPA, TCP-IP@SRI-NIC.ARPA, Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA, gateway-tf@USC-ISIB.ARPA, Mathis@SRI-KL.ARPA
Dave,
   (Flame on -- better put on your fire suit)

   Of course you have chairman's perogative, but I would hate to see
the gateway task force bogged down by what, in the short term, is such
a truely operational concern that the people involved (both DCA and
BBN) should be embarrassed that this issue has surfaced and we (as
users) should be concerned that no solution has been forthcoming.
   Where is this great INOC that BBN requires implementers to discover
that the routing table is full; where is the butterfly gateway to save
us, and where is the management controls that let any random site fill
up the MILNET (core) gateways with networks without DCA approval.  On
this last point, I don't mean that DCA should "bless" every network
before it can be put on the internet; but in a situation of scare
resources (table slots) some management direction must be supplied for
the good of the MILNET/ARPANET community.  Besides, filling up a gateways
routing table with bogus networks is a great way to attack a network
(hope the Russians don't have EGP yet).
   I'm sure some back-pressure could reduce the number of networks.
(For example, SRI has 3 class-B Ethernets.  Early on, the reason for 3
Ethernet cables in the same building were political & traffic density
concerns; in retrospect we could survive with 1 network number if
appropriate back-pressure had been applied.)  If all the people that
have asked for network numbers gets their acts together and buy
gateways, the core will be in big problems.
   The main issues appear to be proper technical guidance and
operational management; for that we need the "fire fighting" task
force with proper funding and not the GADS which survives by skimming
money from research contracts.  I don't even know what more the GADS
or the IAB can do; the direction has been clear: build/install more
capable gateways (butterflys), improve the routing algorithms (SPF and
son of GGP) and implement subnets.  The GADS should spend its limited
time and energies on new internet architectures.

with 20/20 hindsight and apologies to the unjustly roasted,
Jim
-------
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 1985 14:21-PST
From:      the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA>
To:        mike@BRL.ARPA
Cc:        lmaybaum@DDN1.ARPA, TCP-IP@SRI-NIC.ARPA Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA Baker@USC-ISI.ARPA
Subject:   Re:  Gateway Slots
With respect to gateway slots filling up, can anyone explain, why
in this day and age of endless approvals and OK's from upon high
for the trivialest of things, such as controlling net access down
to the RS-232 terminal port level on TACs its possible for anyone
to just "plug a gateway in" and your up?

it's my impression that to join in the internet club these days you
just find a friendly site that lets you plug into their local net
and you then EGP your existence out to the world.  None of this
paper work "stuff" like you need to do now on enabling a TAC ports
to connect a simple terminal up to!

Can anyone explain why there is such control over hooking
terminals onto TAC's when there is no control over hooking
gateways onto the Internet?

Has anyone dumped the gateway routing tables just to see what the
difference between "who is out there" and "who is authorized to
be connected out there is"?  What prevents anyone else from adding on?

g
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Dec-85 11:39:00 EST
From:      JOHNSON@NORTHEASTERN.CSNET (Chris Johnson)
To:        mod.protocols.tcp-ip
Subject:   Info request.


     Hello! 

     At Northeastern University we are building an ethernet LAN with a 
still somewhat amorphous topology.

     I am considering buying various vendor's implementations of TCP-IP
Two that come to mind are The Wollongong Group's for VAX/VMS and Data
General's for AOS/VS.  Data General's seems to be somewhat limited in 
that they don't provide an SMTP (among other things) that I can find.  

     Are there any users for these out there?  I'm interested in bug
reports, functionality reports, ease of use (all kinds) reports, or
reasonable rumors if there are any.  Do these two implementations talk
to each other (I should hope) and  Berkeley 4.2 or higher?

     Any and all information or experience will be much appreciated.

     The list in general may be interested but my address is below.

     Thank you.

Chris Johnson

johnson@northeastern                                  (CSNet)
johnson%northeastern@csnet-relay                      (ARPAnet)

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Dec-85 12:35:33 EST
From:      Mathis@SRI-KL.ARPA
To:        mod.protocols.tcp-ip
Subject:   (none)

Dave,
   (Flame on -- better put on your fire suit)

   Of course you have chairman's perogative, but I would hate to see
the gateway task force bogged down by what, in the short term, is such
a truely operational concern that the people involved (both DCA and
BBN) should be embarrassed that this issue has surfaced and we (as
users) should be concerned that no solution has been forthcoming.
   Where is this great INOC that BBN requires implementers to discover
that the routing table is full; where is the butterfly gateway to save
us, and where is the management controls that let any random site fill
up the MILNET (core) gateways with networks without DCA approval.  On
this last point, I don't mean that DCA should "bless" every network
before it can be put on the internet; but in a situation of scare
resources (table slots) some management direction must be supplied for
the good of the MILNET/ARPANET community.  Besides, filling up a gateways
routing table with bogus networks is a great way to attack a network
(hope the Russians don't have EGP yet).
   I'm sure some back-pressure could reduce the number of networks.
(For example, SRI has 3 class-B Ethernets.  Early on, the reason for 3
Ethernet cables in the same building were political & traffic density
concerns; in retrospect we could survive with 1 network number if
appropriate back-pressure had been applied.)  If all the people that
have asked for network numbers gets their acts together and buy
gateways, the core will be in big problems.
   The main issues appear to be proper technical guidance and
operational management; for that we need the "fire fighting" task
force with proper funding and not the GADS which survives by skimming
money from research contracts.  I don't even know what more the GADS
or the IAB can do; the direction has been clear: build/install more
capable gateways (butterflys), improve the routing algorithms (SPF and
son of GGP) and implement subnets.  The GADS should spend its limited
time and energies on new internet architectures.

with 20/20 hindsight and apologies to the unjustly roasted,
Jim
-------

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Dec 85 12:39 EDT
From:      Chris Johnson <JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip@sri-nic.arpa, johnson%northeastern.csnet@CSNET-RELAY.ARPA
Subject:   Info request.
     Hello! 

     At Northeastern University we are building an ethernet LAN with a 
still somewhat amorphous topology.

     I am considering buying various vendor's implementations of TCP-IP
Two that come to mind are The Wollongong Group's for VAX/VMS and Data
General's for AOS/VS.  Data General's seems to be somewhat limited in 
that they don't provide an SMTP (among other things) that I can find.  

     Are there any users for these out there?  I'm interested in bug
reports, functionality reports, ease of use (all kinds) reports, or
reasonable rumors if there are any.  Do these two implementations talk
to each other (I should hope) and  Berkeley 4.2 or higher?

     Any and all information or experience will be much appreciated.

     The list in general may be interested but my address is below.

     Thank you.

Chris Johnson

johnson@northeastern                                  (CSNet)
johnson%northeastern@csnet-relay                      (ARPAnet)
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Dec-85 17:21:00 EST
From:      Geoff@SRI-CSL.ARPA (the tty of Geoffrey S. Goodfellow)
To:        mod.protocols.tcp-ip
Subject:   Re:  Gateway Slots

With respect to gateway slots filling up, can anyone explain, why
in this day and age of endless approvals and OK's from upon high
for the trivialest of things, such as controlling net access down
to the RS-232 terminal port level on TACs its possible for anyone
to just "plug a gateway in" and your up?

it's my impression that to join in the internet club these days you
just find a friendly site that lets you plug into their local net
and you then EGP your existence out to the world.  None of this
paper work "stuff" like you need to do now on enabling a TAC ports
to connect a simple terminal up to!

Can anyone explain why there is such control over hooking
terminals onto TAC's when there is no control over hooking
gateways onto the Internet?

Has anyone dumped the gateway routing tables just to see what the
difference between "who is out there" and "who is authorized to
be connected out there is"?  What prevents anyone else from adding on?

g

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Dec-85 17:48:19 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   (Response to message)

In response to your message sent  Fri 13 Dec 85 09:35:33-PST

Jim,

I'm very glad to hear you say that. As you know, I have been hammering
for a "Technology Transfer Task Force" which could more properly hack
the operational issues than GADS. It would seem that Mitre, as staff to
DDN PMO, would be the ideal focal point for that. Meanwhile, the buck keeps
landing at our airport.

Perhaps we should continue this via the GADS repeater or direct.

Dave
-------

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Dec-85 21:45:29 EST
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Re:  Gateway Slots

The the response form issued with a new network number includes a statement
about how your network can not be connected to the core without prior
approval from the NIC, and that you also need to become part of a registered
Autonomous System.

However, there is presently no room for either the code or data needed to
validate A.S.  numbers in the core gateways, so there is nothing which
prevents people from just plugging in.

The source of the current problem is that now that 4.2BSD UNIX is capable of
being a full EGP gateway, lots of people are getting LANs and connecting
them.  Indeed, the single most common gateway system on the InterNet these
days is 4.2BSD, somewhat to the surprise of the original networking folks.

Implementing subnets will take some of the strain off (if we can do it fast
enough), but converting to subnet numbers requires a massive change in all
local host addresses.  Also, for those of us who purchase TCP-speaking
devices (like laser printers, LISP machines, etc) from random vendors, we
must depend on the vendor to implement subnet support.  As the RFC
documenting the subnet strategy is fairly recent, not all vendors have taken
notice yet.  Some vendors (most notably Excelan) are still struggling with
things like IP routing and ICMP (sigh), and their boards are found in many
current "off the shelf" products.

We at BRL are working towards reducing the number of network numbers we
require, but currently I expect it to take us another month or two to really
make progress in this direction; others will need similar time to undertake
implementing subnet routing within their gateways, and then convert their
hosts.  I would wager that the subnet tide will not turn until 4.3BSD is in
widespread use.  Even if 4.3 tapes were to teleport out to all 4.2 sites
tomorrow, it would take most sites a month or two to switch, so 4.3 is not
the cure to our immediate woes.

I predict that if everything goes well, and all the core gateways are
enhanced to 11/23 systems, and most sites drop back to using just one or two
net numbers, that we might just barely survive the continued InterNet growth
until the GGP replacement (core IGP, really) is designed and implemented.
Maybe.

	Best,
	 -Mike

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Dec 85 21:45:29 EST
From:      Mike Muuss <mike@BRL.ARPA>
To:        GEOFF@sri-csl.arpa
Cc:        mike@BRL.ARPA, LMaybaum@ddn1.arpa, tcp-ip@sri-nic.arpa, Bloom@monet.berkeley.edu, dca-pgs@ddn1.arpa, Baker@usc-isi.arpa, Perry@ipto.arpa
Subject:   Re:  Gateway Slots
The the response form issued with a new network number includes a statement
about how your network can not be connected to the core without prior
approval from the NIC, and that you also need to become part of a registered
Autonomous System.

However, there is presently no room for either the code or data needed to
validate A.S.  numbers in the core gateways, so there is nothing which
prevents people from just plugging in.

The source of the current problem is that now that 4.2BSD UNIX is capable of
being a full EGP gateway, lots of people are getting LANs and connecting
them.  Indeed, the single most common gateway system on the InterNet these
days is 4.2BSD, somewhat to the surprise of the original networking folks.

Implementing subnets will take some of the strain off (if we can do it fast
enough), but converting to subnet numbers requires a massive change in all
local host addresses.  Also, for those of us who purchase TCP-speaking
devices (like laser printers, LISP machines, etc) from random vendors, we
must depend on the vendor to implement subnet support.  As the RFC
documenting the subnet strategy is fairly recent, not all vendors have taken
notice yet.  Some vendors (most notably Excelan) are still struggling with
things like IP routing and ICMP (sigh), and their boards are found in many
current "off the shelf" products.

We at BRL are working towards reducing the number of network numbers we
require, but currently I expect it to take us another month or two to really
make progress in this direction; others will need similar time to undertake
implementing subnet routing within their gateways, and then convert their
hosts.  I would wager that the subnet tide will not turn until 4.3BSD is in
widespread use.  Even if 4.3 tapes were to teleport out to all 4.2 sites
tomorrow, it would take most sites a month or two to switch, so 4.3 is not
the cure to our immediate woes.

I predict that if everything goes well, and all the core gateways are
enhanced to 11/23 systems, and most sites drop back to using just one or two
net numbers, that we might just barely survive the continued InterNet growth
until the GGP replacement (core IGP, really) is designed and implemented.
Maybe.

	Best,
	 -Mike
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Dec-85 11:45:35 EST
From:      martin%blade@MOUTON.ARPA (Martin J Levy)
To:        mod.protocols.tcp-ip
Subject:   Re:  Gateway Slots

as an extra note to the one about TAC terminal connections and gateways
connections being respectively both hard and easy, i would also like to
ask the question:

"why are core gateways still 11/03's and not 11/23's or even 73's?"

in these days, with the reduced cost of these processors and memory,
and even with the software knowledge of how to program the memory
mapping registers of these processors why is there still a restriction
on the numbers of network numbers that can be held in the gateways
memory. if i remember correct the C-GATE and the BRL gateways both use
memory mapped code.

please don't take this as a vote against subnetting, but more of a note
that is worried about what will happen later, what the number of
networks goes up. the subnet solution will help big sites (like us),
but not with lots of small sites, where one cable is all they have
anyway.

martin levy.
bellcore, nj.

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Dec-85 06:06:24 EST
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re:  Gateway Slots

There have been a couple of messages implying that you can just plug
into the Internet.  We connected a gateway a few months ago.  At that
time, it was necessary to get approval to connect a network to the
Internet.  It was also necessary to get approval to change which machine
acted as a gateway.

As you probably know, there is a separate process to apply for an
Internet network number.  It is interesting in the context of this
discussion that the application implies that the authorities would
rather give you a class C address or a range of class C addresses
than a single class B address.  In fact an industrial group which I have
been working with did get a range of class C addresses.  (They have no
immediate plans to connect to the Internet.)

-------

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Dec-85 08:15:39 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tim Fallon


	Good ! and at last... the address i wanted.

	Could you please send the appropriate paperwork to me
	for tcp/ip (vms) at the following ???

	Ron Tribble
	Ford Motor Company
	p/o Box 6010
	D.P.T.C. Building
	E.E.D. Room B206
	Dearborn, Michigan  48124

	We are looking for a good link between Vax and *ix machines.
	We also need the dope for tcp on *ix machines.

	Thanks Much in advance

	ron tribble

	mb2c!eed092!ron

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 85 15:31:00 PST
From:      <lars@acc.arpa>
To:        "tcp-ip" <tcp-ip@nic>
Cc:        lars
Subject:   ARPAnet Users' Forum at DECUS
In the hope of seeing the faces that go with the names familiar to
readers of the INFO-VAX bulletin board, I called a BOF session at
DECUS, titled "ARPAnet User's Forum".

Probably the title was misleading, for none of the people I had
expected to see showed up; instead there were a number of people
interested in the politics of ARPAnet, foremost among these
Dr Dennis Perry from Los Alamos Natl Labs, who is the head of
DARPA/IPTO, and thus chief of ARPAnet.

Dr Perry gave a very interesting overview of the questions facing
DARPA, including the following (this is typed from my personal
notes; my apologies for any inaccuracies and misunderstandings):

 - how long will the core gateways survive politically ?

 - how long will the core gateways survive technically,
   and how can the technical problems be resolved
   (Domain-severs for IP routing, anyone ?) ?

 - if ARPAnet were gone tomorrow, would anyone miss it ?
   (the current net is no longer a "research net" but a
   production network; the days when you could take the 
   network down for a day to test a new routing algorithm
   are long gone). The issues in the net today are engineering
   problems, not research problems.

 - if we could provide giga-bit links, could anyone think of something
   useful to do with them, other than slice them into smaller pieces ?

Discussions are underway about merging the various research networks
into a new joint administration, encompassing DARPA, NASA, NSF etc.
It is hoped that this can raise 20 million dollars of new funding.

- - -

Next year, it would be interesting to have three different sessions:

- one like this one
- one for TCP-IP readers
- and the INFO-VAX one.

			/ Lars Poulsen
			  Advanced Computer Communications
			 <Lars @ ACC.ARPA>
------
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Dec-85 18:31:00 EST
From:      lars@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   ARPAnet Users' Forum at DECUS

In the hope of seeing the faces that go with the names familiar to
readers of the INFO-VAX bulletin board, I called a BOF session at
DECUS, titled "ARPAnet User's Forum".

Probably the title was misleading, for none of the people I had
expected to see showed up; instead there were a number of people
interested in the politics of ARPAnet, foremost among these
Dr Dennis Perry from Los Alamos Natl Labs, who is the head of
DARPA/IPTO, and thus chief of ARPAnet.

Dr Perry gave a very interesting overview of the questions facing
DARPA, including the following (this is typed from my personal
notes; my apologies for any inaccuracies and misunderstandings):

 - how long will the core gateways survive politically ?

 - how long will the core gateways survive technically,
   and how can the technical problems be resolved
   (Domain-severs for IP routing, anyone ?) ?

 - if ARPAnet were gone tomorrow, would anyone miss it ?
   (the current net is no longer a "research net" but a
   production network; the days when you could take the 
   network down for a day to test a new routing algorithm
   are long gone). The issues in the net today are engineering
   problems, not research problems.

 - if we could provide giga-bit links, could anyone think of something
   useful to do with them, other than slice them into smaller pieces ?

Discussions are underway about merging the various research networks
into a new joint administration, encompassing DARPA, NASA, NSF etc.
It is hoped that this can raise 20 million dollars of new funding.

- - -

Next year, it would be interesting to have three different sessions:

- one like this one
- one for TCP-IP readers
- and the INFO-VAX one.

			/ Lars Poulsen
			  Advanced Computer Communications
			 <Lars @ ACC.ARPA>
------

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Dec-85 22:32:00 EST
From:      CERF@USC-ISI.ARPA
To:        mod.protocols.tcp-ip
Subject:   Christmas Thoughts


 
                   'Twas the Night Before Start-up
 
 
'Twas the night before start-up and all through the net,
  not a packet was moving; no bit nor octet.
The engineers rattled their cards in despair,
  hoping a bad chip would blow with a flare.
The salesmen were nestled all snug in their beds,
  while visions of data nets danced in their heads.
And I with my datascope tracings and dumps
  prepared for some pretty bad bruises and lumps.
When out in the hall there arose such a clatter,
  I sprang from my desk to see what was the matter.
 
There stood at the threshold with PC in tow,
  An ARPANET hacker, all ready to go.
I could see from the creases that covered his brow,
  he'd conquer the crisis confronting him now.
More rapid than eagles, he checked each alarm
  and scrutinized each for its potential harm.
 
On LAPB, on OSI, X.25!
  TCP, SNA, V.35!
 
His eyes were afire with the strength of his gaze;
  no bug could hide long; not for hours or days.
A wink of his eye and a twitch of his head,
  soon gave me to know I had little to dread.
He spoke not a word, but went straight to his work,
  fixing a net that had gone plumb berserk;
And laying a finger on one suspect line,
  he entered a patch and the net came up fine!
 
The packets flowed neatly and protocols matched;
  the hosts interfaced and shift-registers latched.
He tested the system from Gateway to PAD;
  not one bit was dropped; no checksum was bad.
At last he was finished and wearily sighed
  and turned to explain why the system had died.
I twisted my fingers and counted to ten;
  an off-by-one index had done it again...
 
 
-Vint Cerf
 December 1985
 

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Dec-85 05:41:00 EST
From:      Vshank@WEIZMANN.BITNET (Henry Nussbacher)
To:        mod.protocols.tcp-ip
Subject:   New disussion forum

This is to announce a new discussion forum group: Ibm-Nets.  Anything
relating to IBM mainframes and networking is valid for this discussion
group.  Examples:

Tcp/Ip and VM or MVS
   Wisconson Wiscnet
   Spartacus Knet
X.25
Ethernet
Pronet
SNA
Vnet
Bitnet NJE protocols
or anything else that is related to IBM mainframes and networking.

To subscribe to this list send mail to:

Bitnet:   Info@Bitnic
Internet: Info%Bitnic.Bitnet@Wiscvm.Wisc.Edu

Please specify that you wish to be subscribed/unsubscribed to Ibm-Nets.

To send contributions to this list (it is an immediate redistribution
list with no filtering or digesting), send mail to:

Bitnet:   Ibm-Nets@Bitnic
Internet: Ibm-Nets%Bitnic.Bitnet@Wiscvm.Wisc.Edu

Coordinator: Henry Nussbacher (Hank@Bitnic or
                               Hank%Bitnic.Bitnet@Wiscvm.Wisc.Edu)

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Dec-85 14:25:04 EST
From:      narten@PURDUE.EDU ("Thomas Narten")
To:        mod.protocols.tcp-ip
Subject:   wanted: TCP retransmission timer calculation info

I am doing some work with TCP running on slow speed (9600 baud) full
duplex lines. Hosts may be directly connected, or be separated by
several hops. Measurements show round trip times exceeding 4-5 seconds.
Throughput is severely degraded, due to TCP retransmissions.

I am looking for algorithms (and references to them) for computing
retransmission timer values. I have had no luck so far in finding
references to any. Can someone point me to references for the one used
under 4.2 UNIX or any other system? 

Please respond by mail, as I am not on this mailing list (yet).

Thanks,
Thomas Narten
narten@purdue.EDU
----------

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Dec-85 14:37:49 EST
From:      mckenzie@BBNH.ARPA (Alex McKenzie)
To:        mod.protocols.tcp-ip
Subject:   Re: ARPAnet Users' Forum at DECUS

I don't know when it was true that "you could take the network down for a day
to test a new routing algorithm," but it certainly wasn't true by 1972, when I
became responsible for Network Operations.  It was true that we had a
2-hour/week time slot reserved for testing, but the users in those days would
never have accepted a one-day outage.

Alex McKenzie

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Dec 85 14:37:49 EST
From:      Alex McKenzie <mckenzie@BBNH.ARPA>
To:        <lars@acc.arpa>
Cc:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Re: ARPAnet Users' Forum at DECUS
I don't know when it was true that "you could take the network down for a day
to test a new routing algorithm," but it certainly wasn't true by 1972, when I
became responsible for Network Operations.  It was true that we had a
2-hour/week time slot reserved for testing, but the users in those days would
never have accepted a one-day outage.

Alex McKenzie

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1985 19:28:38 PST
From:      POSTEL@USC-ISIB.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: retransmission time out calculations

Thomas Narten:

Try page 41 of RFC-793, and RFC-813.

--jon.
-------
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Dec 1985 12:41 O
From:      Henry Nussbacher, <Vshank%Weizmann.BITNET@WISCVM.WISC.EDU>
To:        <tcp-ip@sri-nic.ARPA>
Subject:   New disussion forum
This is to announce a new discussion forum group: Ibm-Nets.  Anything
relating to IBM mainframes and networking is valid for this discussion
group.  Examples:

Tcp/Ip and VM or MVS
   Wisconson Wiscnet
   Spartacus Knet
X.25
Ethernet
Pronet
SNA
Vnet
Bitnet NJE protocols
or anything else that is related to IBM mainframes and networking.

To subscribe to this list send mail to:

Bitnet:   Info@Bitnic
Internet: Info%Bitnic.Bitnet@Wiscvm.Wisc.Edu

Please specify that you wish to be subscribed/unsubscribed to Ibm-Nets.

To send contributions to this list (it is an immediate redistribution
list with no filtering or digesting), send mail to:

Bitnet:   Ibm-Nets@Bitnic
Internet: Ibm-Nets%Bitnic.Bitnet@Wiscvm.Wisc.Edu

Coordinator: Henry Nussbacher (Hank@Bitnic or
                               Hank%Bitnic.Bitnet@Wiscvm.Wisc.Edu)
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Dec-85 22:28:38 EST
From:      POSTEL@USC-ISIB.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: retransmission time out calculations


Thomas Narten:

Try page 41 of RFC-793, and RFC-813.

--jon.
-------

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 18 Dec 1985 07:37-PST
From:      decwrl!pyramid!nsc!csi!ggere@ucbvax.berkeley.edu
To:        nsc!tcp-ip
To: nsc!pyramid!decwrl!ucbvax!tcp-ip
Subject: Re: New disussion forum
Newsgroups: mod.protocols.tcp-ip
In-Reply-To: <8512171923.AA01763@ucbvax.berkeley.edu>
Organization: Communications Solutions Inc. 992 S.Saratoga-Sunnyvale Rd, San Jose, CA 95129
Cc: 
--------
Hi:
 I wish to subscribe to the ibm-net discussion group. Since I am not on
the BITNET or INTERNET, I am replying directly to the soliciting message.

===============================================================================
Communications Solutions  992 S. Saratoga-Sunnyvale Road  San Jose, Calif 95129
Gary M. Gere {bnrmtv,fortune,unisoft,nsc,dual}!csi!ggere 4087251568
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Dec-85 09:55:00 EST
From:      Vshank@WEIZMANN.BITNET (Henry Nussbacher)
To:        mod.protocols.tcp-ip
Subject:   Ibm-nets revision

If you haven't subscribed yet but intend to do not send your request to
Info@Bitnic.Bitnet but rather to Hank@Bitnic.Bitnet.

Hank

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Dec-85 12:22:00 EST
From:      DCP@SCRC-QUABBIN.ARPA (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   wanted: TCP retransmission timer calculation info


    Date: 17 Dec 85 14:25:04 EST (Tue)
    From: "Thomas Narten" <narten@Purdue.EDU>

    I am doing some work with TCP running on slow speed (9600 baud) full
    duplex lines. Hosts may be directly connected, or be separated by
    several hops. Measurements show round trip times exceeding 4-5 seconds.
    Throughput is severely degraded, due to TCP retransmissions.

    I am looking for algorithms (and references to them) for computing
    retransmission timer values. I have had no luck so far in finding
    references to any. Can someone point me to references for the one used
    under 4.2 UNIX or any other system? 

    Please respond by mail, as I am not on this mailing list (yet).

    Thanks,
    Thomas Narten
    narten@purdue.EDU

I'll repeat something I've claimed for 2 years: The simple adapative
retransmission algorithms (one of which I think is actually in the TCP
spec) are all meta-stable.  If you start retransmitting too fast, you
will continue to retransmit too fast and you will actually start going
faster.  If you retransmit too slow, you will start retransmitting
slower.

I suggest NOT looking at the Unix code.  (Aside from strong personal
biases against Unix...) As I recall from experience, Unix does well over
fast links, but on slow links it isn't bad; it is pessimal.  It tries to
adapt but loses until it bottoms out at a retransmission interval of 10
seconds.  Even if the link becomes instantaneous, Unix will never
notice.

Segue into JNC describing research at MIT regarding non-simple adaptive
retransmission algorithms that may work...

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Dec-85 13:38:37 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: retransmission time out calculations

In response to the message sent  17 Dec 1985 19:28:38 PST from POSTEL@USC-ISIB.ARPA

Thomas,

See also page 10 et seq of RFC-889 for refinements to the algorithm.

Dave
-------

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Dec-85 15:43:07 EST
From:      kjl@BBN-CLXX.ARPA (Ken Lebowitz)
To:        mod.protocols.tcp-ip
Subject:   off-board TCP/IP processors


[I don't know if anyone has previously asked for this but I'll try anyway]

Has somebody ever compared the performance of the various off-board TCP/IP
processors available for the multibus (Excelan, CMC, Interlan...)?
Actually, I'm interested in any experience(s) that people have had with
these devices (good, bad or whatever).  Please direct your replies to me
since I'm not a member of the TCP-IP mailing list.

Many thanks,

Ken Lebowitz
BBN Laboratories
Cambridge, MA

ARPA:	kjl@bbn-clxx.arpa
CSNET:	kjl%bbn-clxx.arpa@csnet-relay
UUCP:	...!{ihnp4,decvax}!bbncca!kjl
DOMAIN:	kjl@clxx.bbn.com

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Dec 85 15:43:07 EST
From:      Ken Lebowitz <kjl@bbn-clxx.arpa>
To:        tcp-ip@nic
Subject:   off-board TCP/IP processors

[I don't know if anyone has previously asked for this but I'll try anyway]

Has somebody ever compared the performance of the various off-board TCP/IP
processors available for the multibus (Excelan, CMC, Interlan...)?
Actually, I'm interested in any experience(s) that people have had with
these devices (good, bad or whatever).  Please direct your replies to me
since I'm not a member of the TCP-IP mailing list.

Many thanks,

Ken Lebowitz
BBN Laboratories
Cambridge, MA

ARPA:	kjl@bbn-clxx.arpa
CSNET:	kjl%bbn-clxx.arpa@csnet-relay
UUCP:	...!{ihnp4,decvax}!bbncca!kjl
DOMAIN:	kjl@clxx.bbn.com

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Dec 85 16:23:07 EST
From:      Chris Torek <chris@gyre.umd.edu>
To:        narten@Purdue.EDU
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  wanted: TCP retransmission timer calculation info
You do not want to use the 4.2 retransmission timer algorithm.  It
throws out timing data that appears to be `too long'.  The criterion
for determining whether a packet has taken too long to be counted
in retransmission delay adjustment is whether it has been retransmitted.
Thus with a very slow link, *every* packet is retransmitted; and
none are counted, so the time never gets adjusted.

Chris
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Dec 1985 16:55 O
From:      Henry Nussbacher, <Vshank%Weizmann.BITNET@WISCVM.WISC.EDU>
To:        Ibm-nets revision <tcp-ip@sri-nic.ARPA>
Subject:   Ibm-nets revision
If you haven't subscribed yet but intend to do not send your request to
Info@Bitnic.Bitnet but rather to Hank@Bitnic.Bitnet.

Hank
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Dec 85 13:59:27 pst
From:      michael@cit-vlsi.ARPA (Michael Lichter)
To:        tcp-ip@sri-nic.arpa
Subject:   excelan 3.1
Does anybody have a version of excelan 3.1 tcp/ip for Xenix on the
iNTEL 286/310 patched so that it doesn't die continually with
icmp-related panics?  Thanks.

Michael
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 85 16:48:00 PST
From:      <lars@[unknown]>
To:        "tcp-ip" <tcp-ip@nic>
Cc:        info-vax@sri-kl,perry@ipto, lars
Subject:   Corrigendum: ARPAnet Users' Forum at DECUS
I have received numerous notes pointing out errors in my submission
about the ARPAnet user meeting at DECUS, and I hope the following
note from Dr. Perry will serve to set the record straight. I hope
my errors have not caused too many problems.

			/ Lars Poulsen
			  Advanced Computer Communications
			 <Lars @ ACC.ARPA>

--------------------- Forwarded mail follows ---------------------------

Date: Thu 19 Dec 85 08:40:59-EST
From: Dennis G. Perry <PERRY@IPTO.ARPA>
Subject: Re: Did I get it right ?
To: lars@ACC.ARPA

Lars, a few notes to help you out.  I am from Los Alamos National Lab
on exchange to DARPA.  In DARPA I am a program manager in charge of
most of the network programs, including the Arpanet.  I am in the
Information Processing Techniques Office of DARPA.  Our office director
is Dr. Saul Amarel, from Rutgers University.

Some of my comments as I noted were designed to get some sort of feed
back from attendees at the meeting and did not imply any actual
activity to implement any of the discussion topics.

In particular, I did not mean to imply that research is not warrented
in the Arpanet, but that many of the issues that need to be resolved
appear to be shorter term issues, along the lines of advanced
engineering or short term research.  To properly address the research
issues, DARPA wants to look at much longer term issues, hence the interest
in very high speed networking.

The discussion about merging the various research networks is a little
misleading.  The idea here was to formalize the Arpa-Internet to
provide a more active participation of its development by other
agencies.  The amount of money mentioned was pure speculation, since
the discussions are very, very preliminary.

Thanks for the opportunity to make a few comments, both here and at DECUS.

dennis
-------
------
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Dec-85 02:36:42 EST
From:      karn@MOUTON.ARPA (Phil R. Karn at mouton.ARPA)
To:        mod.protocols.tcp-ip
Subject:   TCP retransmissions in 4.2BSD UNIX

I believe the behavior you describe is the fault of the 4.2BSD
implementation, not the adaptive algorithm in RFC-793 (although it could be
improved; see Mills' RFC-889 on Internet delay experiments).

The version we had (which admittedly had been hacked extensively before we
got it) restarted the round trip timer whenever a retransmission timeout
occurred. If the retransmission is caused by a low RTT estimate rather than
a dropped packet, resetting the timer causes it to measure the time between
the second (or later) transmission attempt and the arrival of the first
transmission's ack. Obviously this results in an erroneously low round trip
estimate, thus perpetuating the problem.  Since the initial RTT estimate was
far too short to begin with (.5 sec), this guarantees lousy performance over
a slow link, with little or no chance for adaptation.

I've hacked our version to leave the round trip timer alone during
retransmissions. This does compute an erroneously LONG estimate of RTT when
the path is lossy, but since network congestion is probably the single
biggest cause for dropped packets anyway it seems better to err in this
direction. An initial estimate of 5 seconds seems to work well over our
(very slow) X.25/CSNET connection to the Internet.

I also highly recommend the Nagle tinygram-avoidance technique (RFC896).
It makes a world of difference when running across slow links.

Phil Karn

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Dec-85 08:26:40 EST
From:      GJC@MIT-MC.ARPA ("George J. Carrette")
To:        mod.protocols.tcp-ip
Subject:   excelan 3.1

I think you better go to version 3.2, since I never got 3.1 to do anything
reasonable related to icmp. But what do you mean by patch? Actually patch
the binary downloaded software? 

Could everybody using Excelan stuff send me a note so we could have a
subdiscussion about related issues?

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Dec-85 19:51:38 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Bridge CS/100 and 4.2BSD

We are considering a Bridge CS/100 TCP/IP terminal server as
an alternative for a regular Sun line multiplexer.  It seems
fine for terminals but what about lines attached to printers
and dial-out modems?  

Is it possible to configure a 4.2bsd printer spooler and uucp
so that the device (printer or auto-caller) is attached to CS/100?
Generally, can the computer make a CS/100 line look like 
an ordinary (pseudo) terminal device?

	Juha Heinanen (jh@utacs.uucp or jh%utacs.uucp@seismo)

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1985 06:01:42 PST
From:      "Vinton G. Cerf / MCI ID: 105-0002" <INTERMAIL@USC-ISIF.ARPA>
To:        TCP-IP@SRI-NIC.ARPA, Postel@USC-ISID.ARPA
Subject:   Network Christmas Carols

Date:     Mon Dec 23, 1985  4:57 am  PDT
From:     Vinton G. Cerf / MCI ID: 105-0002
 
TO:     * Intermail / MCI ID: 107-8239
Subject:  Network Christmas Carols
 

 
                  Oh OSI, oh OSI
 
                        (to the tune of O Tannenbaum)
 
        Oh OSI, oh OSI,
        Your rules are always changing.
        Oh OSI, oh OSI,
        Your rules are always changing.
 
        Each year you bring new protocols,
        More overhead and service calls.
        Oh OSI, oh OSI
        Your rules are always changing.
 
        Oh OSI, oh OSI,
        With seven layers burdened.
        Oh OSI, oh OSI,
        With seven layers burdened.
 
        Perhaps one day I'll live to see
        A multi-vendor community!
        Oh OSI, oh OSI,
        With endless promise laden.
 
        Oh OSI, oh OSI,
        Your rules are ever changing.
        Oh OSI, oh OSI,
        Your rules are ever changing.
 
- Vint Cerf
  December 1985
--------------------------------------------------------------------

 
 
 
                DEC the Halls
 
        DEC the halls with stuff from Reading!
        Fa la la la la, la la la la.
        Where the hell is DECNET heading?
        Fa la la la la, la la la la.
 
        IBM confuses matters.
        Fa la la, la la la, la, la, la.
        SNA is Chutes and Ladders! (tm)
        Fa la la la la, la, la, la, la.
 
        BBN is here to help me!
        Fa la la, la la la, la, la, la.
        Where's my gosh darn X.PC?  [pronounced "X dot PC"]
        Fa la la la la, la, la, la, la.
 
        Never fear, here's eager HP!
        Fa la la la la, la la la la.
        Full of DS, linking lightly.
        Fa la la la la, la la la la.
 
        NT works in bits and snatches;
        Fa la la, la la la, la, la, la.
        Service data rarely matches!
        Fa la la la la, la, la, la, la.
 
        What a dizzy zoo before us!
        Fa la la la la, la la la la.
        Tune the net and join the chorus!
        Fa la la la la, la, la, la, la!
 
 
 
- Vint Cerf
  December 1985
 

-------
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Mon 23 Dec 85 09:38:27-PST
From:      NADIA@SRI-KL.ARPA
To:        TCP-IP@SRI-NIC.ARPA
Cc:        HAMID@SRI-KL.ARPA
Subject:   ADDITION TO MAILING LIST

PLEASE ADD HAMID TO YOUR MAILING LIST FOR TCP-IP GROUP. THANKS

TAREK ABDEL-HAMID
HAMID@SRI-KL

-------
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Dec-85 09:01:42 EST
From:      INTERMAIL@USC-ISIF.ARPA ("Vinton G. Cerf / MCI ID: 105-0002")
To:        mod.protocols.tcp-ip
Subject:   Network Christmas Carols


Date:     Mon Dec 23, 1985  4:57 am  PDT
From:     Vinton G. Cerf / MCI ID: 105-0002
 
TO:     * Intermail / MCI ID: 107-8239
Subject:  Network Christmas Carols
 

 
                  Oh OSI, oh OSI
 
                        (to the tune of O Tannenbaum)
 
        Oh OSI, oh OSI,
        Your rules are always changing.
        Oh OSI, oh OSI,
        Your rules are always changing.
 
        Each year you bring new protocols,
        More overhead and service calls.
        Oh OSI, oh OSI
        Your rules are always changing.
 
        Oh OSI, oh OSI,
        With seven layers burdened.
        Oh OSI, oh OSI,
        With seven layers burdened.
 
        Perhaps one day I'll live to see
        A multi-vendor community!
        Oh OSI, oh OSI,
        With endless promise laden.
 
        Oh OSI, oh OSI,
        Your rules are ever changing.
        Oh OSI, oh OSI,
        Your rules are ever changing.
 
- Vint Cerf
  December 1985
--------------------------------------------------------------------

 
 
 
                DEC the Halls
 
        DEC the halls with stuff from Reading!
        Fa la la la la, la la la la.
        Where the hell is DECNET heading?
        Fa la la la la, la la la la.
 
        IBM confuses matters.
        Fa la la, la la la, la, la, la.
        SNA is Chutes and Ladders! (tm)
        Fa la la la la, la, la, la, la.
 
        BBN is here to help me!
        Fa la la, la la la, la, la, la.
        Where's my gosh darn X.PC?  [pronounced "X dot PC"]
        Fa la la la la, la, la, la, la.
 
        Never fear, here's eager HP!
        Fa la la la la, la la la la.
        Full of DS, linking lightly.
        Fa la la la la, la la la la.
 
        NT works in bits and snatches;
        Fa la la, la la la, la, la, la.
        Service data rarely matches!
        Fa la la la la, la, la, la, la.
 
        What a dizzy zoo before us!
        Fa la la la la, la la la la.
        Tune the net and join the chorus!
        Fa la la la la, la, la, la, la!
 
 
 
- Vint Cerf
  December 1985
 

-------

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Dec-85 12:38:27 EST
From:      NADIA@SRI-KL.ARPA
To:        mod.protocols.tcp-ip
Subject:   ADDITION TO MAILING LIST


PLEASE ADD HAMID TO YOUR MAILING LIST FOR TCP-IP GROUP. THANKS

TAREK ABDEL-HAMID
HAMID@SRI-KL

-------

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Dec-85 12:47:03 EST
From:      hassler@LOGNET2.ARPA (Barry D. Hassler)
To:        mod.protocols.tcp-ip
Subject:   Addition to Mailing List

Please add me to the mailing list for the TCP-IP group. Thanks.

Barry D. Hassler
hassler@lognet2

Systems Software Analyst
Control Data Corp.

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 1985 03:03:49 PST
From:      "Vinton G. Cerf / MCI ID: 105-0002" <INTERMAIL@USC-ISIF.ARPA>
To:        TCP-IP@SRI-NIC.ARPA, Postel@USC-ISID.ARPA
Subject:   Revision of OSI Carol

Date:     Tue Dec 24, 1985  3:46 am  PDT
From:     Vinton G. Cerf / MCI ID: 105-0002
 
TO:     * Intermail / MCI ID: 107-8239
Subject:  Revision of OSI Carol
 
I added some verses:


 
                  Oh OSI, oh OSI
 
                        (to the tune of O Tannenbaum)
 
        Oh OSI, oh OSI,
        Your rules are always changing.
        Oh OSI, oh OSI,
        Your rules are always changing.
 
        Each year you bring new protocols,
        More overhead and service calls.
        Oh OSI, oh OSI
        Your rules are always changing.
 
        Oh OSI, oh OSI,
        With seven layers burdened.
        Oh OSI, oh OSI,
        With seven layers burdened.
 
        No matter where I turn to look,
        There comes another colored book!
        Oh OSI, oh OSI,
        With variation, sagging!
 
        Oh OSI, oh OSI,
        The source of my frustration!
        Oh OSI, oh OSI,
        The source of my frustration!
 
        A plebescite in 92
        Will split a layer into two;
        Oh OSI, oh OSI,
        Amoebic reproduction!
 
        Oh OSI, oh OSI,
        Eternally unfolding.
        Oh OSI, oh OSI,
        Eternally unfolding
        
        Oh, can the C C I T T
        and I S O at last agree
        On OSI, on OSI,
        The final net solution?
 
        Oh OSI, oh OSI,
        Ever in negotiation!
        Oh OSI, oh OSI,
        Ever in negotiation!
 
        Perhaps one day I'll live to see
        A multi-vendor community!
        Oh OSI, oh OSI,
        With endless promise laden.
 
        Oh OSI, oh OSI,
        Your rules are ever changing.
        Oh OSI, oh OSI,
        Your rules are ever changing.
 
- Vint Cerf
  December 1985

-------
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Dec-85 06:03:49 EST
From:      INTERMAIL@USC-ISIF.ARPA ("Vinton G. Cerf / MCI ID: 105-0002")
To:        mod.protocols.tcp-ip
Subject:   Revision of OSI Carol


Date:     Tue Dec 24, 1985  3:46 am  PDT
From:     Vinton G. Cerf / MCI ID: 105-0002
 
TO:     * Intermail / MCI ID: 107-8239
Subject:  Revision of OSI Carol
 
I added some verses:


 
                  Oh OSI, oh OSI
 
                        (to the tune of O Tannenbaum)
 
        Oh OSI, oh OSI,
        Your rules are always changing.
        Oh OSI, oh OSI,
        Your rules are always changing.
 
        Each year you bring new protocols,
        More overhead and service calls.
        Oh OSI, oh OSI
        Your rules are always changing.
 
        Oh OSI, oh OSI,
        With seven layers burdened.
        Oh OSI, oh OSI,
        With seven layers burdened.
 
        No matter where I turn to look,
        There comes another colored book!
        Oh OSI, oh OSI,
        With variation, sagging!
 
        Oh OSI, oh OSI,
        The source of my frustration!
        Oh OSI, oh OSI,
        The source of my frustration!
 
        A plebescite in 92
        Will split a layer into two;
        Oh OSI, oh OSI,
        Amoebic reproduction!
 
        Oh OSI, oh OSI,
        Eternally unfolding.
        Oh OSI, oh OSI,
        Eternally unfolding
        
        Oh, can the C C I T T
        and I S O at last agree
        On OSI, on OSI,
        The final net solution?
 
        Oh OSI, oh OSI,
        Ever in negotiation!
        Oh OSI, oh OSI,
        Ever in negotiation!
 
        Perhaps one day I'll live to see
        A multi-vendor community!
        Oh OSI, oh OSI,
        With endless promise laden.
 
        Oh OSI, oh OSI,
        Your rules are ever changing.
        Oh OSI, oh OSI,
        Your rules are ever changing.
 
- Vint Cerf
  December 1985

-------

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Dec-85 10:33:17 EST
From:      dfs%a@LANL.ARPA (Don Shafer)
To:        mod.protocols.tcp-ip
Subject:   Drop from Mailing List


Please drop me from your mailing list.

Thanks,

dfs

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Dec-85 12:28:18 EST
From:      walker%cod@NOSC.ARPA (Janet M. Walker)
To:        mod.protocols.tcp-ip
Subject:   Drop from Mailing List

Please drop me from your mailing list.      Thanks,     walker@nosc
-------

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Dec-85 16:44:50 EST
From:      G.ROODE@SU-SCORE.ARPA (David Roode)
To:        mod.protocols.tcp-ip
Subject:   Re: Drop from Mailing List

Please send drop requests to

	TCP-IP-REQUEST@SRI-NIC.ARPA

-------

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Dec-85 19:00:04 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   ip fragmentation follies

I've been playing with IP fragmentation/reassembly and have discovered
a major crock in the Berkeley way of doing things.  This may have been
noticed by someone before, but I hadn't really thought about it.

What caused me to notice this was claims by some people (namely Sun)
that using very large IP packets and using IP-level fragmentation
makes protocols like NFS run faster.  This makes some sense (less
context-switching, etc), so we decided to try it.  We quickly noticed
a problem, though: if a fragmented packet has to be retransmitted (eg
because one of the fragments was dropped somewhere) the fragments of
the retransmitted packet are not and can not be merged with those of
the original packet!  Why?  Because the Berkeley code has no notion of
IP-level retransmission, and hence assigns a new IP-level packet
identifier to each and every IP packet it transmits!  And since the
IP-level identifier is the only way the receiver can tell whether two
fragments belong to the same packet, this means that the fragments of
a retransmitted packet can never be combined with those of the
original.

What all this means in practice is this: for a fragmented IP packet to
get through to its receiver, all the fragments resulting from a single
transmission of that packet must get through.  If a single fragment is
lost, all the other fragments resulting from that transmission of the
packet are useless and will never be recombined with fragments from
past or future transmissions of the same packet.

This all explains (or at least provides a partial explanation) for why
people running 4.2 TCP connections across the Arpanet using 1024-byte
packets were losing so badly.  If the probability of fragment lossage
is even moderately high, it will often take three or more tries to get
a fragmented packet across the net.  Meanwhile, of course, the useless
fragments from previous transmissions are sitting on reassembly queues
in the receiver (for 15 seconds, I think?), tying up buffering
resources and increasing the chances that fragments will be dropped in
the future!

In the current Berkeley code, it's possible to imagine workarounds for
this problem for TCP: because TCP is in the kernel, it could have a
side hook into the IP layer to tell it "this packet is a
retransmission, don't give it a new IP identifier".  For protocols
like UDP, however, the acknowledgment and retransmission functions are
done outside of the kernel, and the only kernel interface that's
available is Berkeley's socket calls (sendto, recvfrom, etc).
Needless to say, the socket interface gives you 1) no way to find out
what IP identifier a packet was sent with; 2) No way to specify the IP
identifier to use on an outgoing packet.

I don't really have any idea what to do about this problem.  And, it's
not entirely Berkeley's fault; the BBN TCP/IP for 4.1bsd did the same
thing...  In any case, until there's a fix I don't think using IP
fragmentation/reassembly when talking to 4.2bsd systems is a very good
idea.
                                                        -Larry

-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Dec-85 14:45:00 EST
From:      Greenwald@SCRC-STONY-BROOK.ARPA (Michael Greenwald)
To:        mod.protocols.tcp-ip
Subject:   ip fragmentation follies


Yeah, it's been noticed.  I thought Dave had even commented on it in his
"implementation notes", but I can't find my copies, so I didn't check it
up.  I noticed this in multics (it hadn't actually happened, but if you
remember I was trying to decide when you'd rather have *large* ip
packets, and when you'd rather restrict ip packets to the max network
size.  IP reassembly was cheaper than TCP reassembly. (fewer packet
headers to process.)  I thought the only drawback was that in case of a
lost fragment, you had to retransmit the entire packet, but when I
thought about it, I made the same realization that you did.)  My
(minimal) solution is mentioned below.

My multics code had foo$retransmit_packet, foo$forward_packet, and
foo$send_packet for each datagram protocol named "foo".  (IP, UDP, GGP,
and ICMP, as far as I can remember.)  Not only did it keep the same ID,
but it eliminated a certain category of error checking and checksum
generation, where possible.

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Dec-85 17:14:56 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: New disussion forum

I wish to describe to the IBM-nets discussion but I am not sure how to
reply.
 Tom Webb at Shell

END OF DOCUMENT