TCP-IP@BRL (09/15/82)
TCP/IP Digest Tuesday, 14 Sept 1982 Volume 1 : Issue 22
Today's Topics:
SAMNET TCP/IP Implementation Observations
Pointer to Gateway Article in Data Communications Magazine
Query about "Standard Gateway" Code
TCP/IP - VDH: Queries and Answers for VAX UNIX
TCP/IP for PWB/UNIX Query && Cray for TCP/IP -- Request for Help
TCP/IP for Intel MDS (8086)?
TCP/IP for Honeywell Level 6? How about IBM MVS?
TCP/IP on a PDP-11/40 with 80Kbytes?
----------------------------------------------------------------------
LIMITED DISTRIBUTION
For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------
Date: 27 Jul 1982 0708-EDT
From: GEORGE at Afsc-Hq
To: tcp-ip at BRL
Subject: Testing SAMNET TCP/IP implementation
In testing the SAMNET (PDP-11, RSX11-M) TCP/IP implementation against
its first service host, the ISI TOPS-20 system, some peculiar aspects
of retransmission are becoming evident. These may be of interest to
other implementors.
First, a few notes about the SAMNET implementation -
The TCP/IP/1822 layers are implemented in a multiprocess task with
internal scheduling on a prioritized basis; lower layers have higher
priority than higher layers, receive side has higher priority than
send side . All told there are about 10 processes with a timer process
which gets a chance to execute once-a-second. As soon as a process
gives up control the highest priority process with a need to execute
gets control. Of course, all this is executing under the RSX11-M
operating system but the TCP/IP/1822 task is generally at a
higher priority than the various user tasks (TELNET and FTP).
At the TCP layer, SEND requests from higher level protocols (TELNET,
FTP) are processed by (1) moving the data to a TCP buffer, (2) freeing
the requestor to issue additional SENDs, and (3) forming TCP segments
to pass to the IP layer. Send-flow is blocked for a connection when
the send-side of the connection owns too many TCP buffer resources for
unacknowledged data octets and segments.
Retransmission timeout is set using the technique illustrated in
RFC793, p41, with ALPHA=15/16, BETA=2, UBOUND=255, and LBOUND=2.
Only the oldest segment will be retransmitted.
The ACK strategy is to delay an ACK until the next second-boundary
unless data is flowing in the direction of the ACK. Issuing
immediate ACKs or timing more frequently places an excessive
burden on processing and seemed impractical.
The IP layer has no significance to the discussion at hand.
At the local net (ARPANET) layer, messages are queued to a host
table if another message is in transit to the destination host.
(Note: the use of "message-ID" field for link number seems to
prevent having more than one message outstanding to a host if
one wants to handle the 1822 IMP-host error messages). Since the
higher layers can produce messages faster than the local net layer
can dispatch them, a queue of messages quickly builds waiting
for the one active output to get a RFNM.
Now for the retransmission pecularities -
(1) When the TCP level decides to retransmit a segment, the IP and
local net layers have no way to be aware that the segment from
TCP should be put at the front of the host table queue, so it
goes to the end of the queue to wait its turn.
A retransmitted segment usually is being passed through the IP and
local net layers when an ACK arrives for the original segment.
The TCP layer discards an ACKed entry from the connection retransmission
queue and uncovers the next entry which perhaps has a retransmission
timeout equivalent to the one just ACKed due to a bursty mode of
segment generation. Frequently, this next segment on the connection
retransmission queue also will get retransmitted just before its ACK
arrives at the TCP layer (this is particularly true when the receiving
host send ACKs for each message arriving).
This situation seems to propagate into an interleaving of
retransmitted segments and new segments as both the TCP segment
generator and the retransmitter do their jobs. The result is that
the IP and local net layers process retransmitted segments even
after an ACK has been processed for the original segment.
A temporary resolution to this problem has been to not put so
much reverence in the calculated response time (especially when
it gets down to the range of 1-2 seconds). When the retransmission
timeout is delayed to twice the calculated response time, the
retransmissions disappeared.
(2) For incoming messages to the SAMNET system, the ACK delay to the
next second-boundary is causing the remote host to retransmit,
sometimes 3-4 times. Of course the outgoing ACK is somewhat
impeded because it's generated by a lower priority process
(high layer, send side) and must contend with the queue which
might exist at the local net host table (in this situation
there's been little contention at the queue because the
data flow was principally incoming).
In both cases the retransmissions have been kicked off by a too-strict
adherence to the retransmission timeout when it is in the range of
1-2 seconds. The highly modularized, layered approach taken by
the SAMNET implementation is producing results that are not entirely
satisfactory. Some more sophisticated cross-talk between the TCP
layer and the IP/local net layer and between the segment generator
and the retransmission processor are being investigated in search
for a more satisfactory performance.
Implementors need to be aware of other implementation internal techniques.
Some dissemination of strategies along the lines of Dave Clark's recent
RFCs will be of use, but we've a ways to go yet.
Chuck Norris (george@afsc-hq)
------------------------------
Date: 17 Aug 1982 12:37:42 EDT (Tuesday)
From: Jack Haverty <haverty@Bbn-Unix>
To: iccb at Bbn-Unix
Subject: Gateway article in Data Communications
Redistributed-by: Bob Hinden <hinden@Bbn-Unix>
Redistributed-to: gateway-info at BBN-UNIX
The August 1982 issue [of Data Communications] contains an article about
the gateway system. It made it through the editorial pass largely
unscathed (at least they didn't put TCP on top of X.25 or some similar
'clarification'...).
Jack
------------------------------
Date: 8-Sep-82 10:00PM-EDT (Wed)
From: Nathaniel Mishkin <Mishkin@Yale>
Subject: Standard Gateway Code
To: Tcp-Ip at BRL
I have a question with what must be an obvious answer: what is the
"Standard Gateway Code available from BBN" that I've seen referred
to on several occasions? I get the impression it runs on -11s. Is
this true? What does it gateway between (among)?
-- Nat
[ The MACRO-11 Gateway is implemented in MACRO-11 for the smaller
PDP-11s, and supports a variety of "standard" network peripherals, such
as the ACC LH/DH-11. ]
------------------------------
Date: 23-Aug-82 9:36AM-EDT (Mon)
From: Nathaniel Mishkin <Mishkin@Yale>
Subject: TCP/IP - VDH Query
To: Tcp-Ip at BRL
I have heard that there exists or someone is working on a VDH driver
for either the BBN 4.1 Unix/IP or the Berkeley 4.2 Unix/IP. Can anyone
supply a pointer?
-- Nat
------------------------------
Date: 4 Sep 82 12:03:29-EDT (Sat)
From: Mark Weiser <mark.umcp-cs@Udel-Relay>
To: unix-wizards at Sri-Csl
cc: tcp-ip at Mit-Ai
Subject: Very Distant Host support under 4.1bsd Unix.
Our 50 kbit line to the Arpanet arrives next month, I thought I was
all prepared by obtaining the IP/TCP kernel from BBN (although I
haven't looked at installing it yet), but now I hear a rumor...
We want to run Very Distant Host protocol directly on our Vax-11/780
running Berkeley 4.1 Unix. Is this possible? Friends at the University
of Rochester tell me they have tried and it doesn't work, only local
host support is any good. Help! Do I really need a C30?
[ For now, you either need ECUs, or a C/30. -Mike ]
------------------------------
Date: 8 Sep 82 4:44:12-EDT (Wed)
From: Doug Kingston <dpk@BRL>
To: Mark Weiser <mark.umcp-cs@Udel-Relay>
cc: unix-wizards at Sri-Csl, tcp-ip at Mit-Ai
Subject: Re: Very Distant Host support under 4.1bsd Unix.
I can't speak to the condition of the VDH (or HDH) code
in 4.1, but even if it worked, you would not want to use it,
the system load of doing all the VDH (HDH) protocol on top of
TCP/IP is prohibitively expensive. A better solution to your
problem of being distant from the IMP, is to buy a pair of ECU's
(error correction units) which are manufactured by the same people
who bring you the LH/DH-11 ArpaNet Interface (ACC, Associated Computer
Consultants). These wonderful boxes are designed to be placed between
the IMP host port and your CPU interface. The ECU at the IMP end looks
like a host, and the ECU at the HOST end looks like an IMP. In the
you hook up the best phone line you can get (the one you would be
running VDH on) and the ECU do the error correction in hardware to
provide an error free link from HOST to IMP. The ECU can look like
a DISTANT or LOCAL host on either end, and the ECU is good for all the
bandwidth you can give it. Its also a lot cheaper than getting another
IMP.
Don't let VDH get you down,
-Doug-
------------------------------
Date: 8 Sep 1982 09:43:45-PDT
From: mo at Lbl-Unix (Mike O'Dell [system])
To: mark.umcp-cs at Udel-Relay
cc: tcp-ip at Mit-Ai
Subject: Re: Very Distant Host support under 4.1bsd Unix.
With all due respect for the people that did the VDH back in the
Dark Ages, the VDH is famous for not working very well. They
have been the cause of premature retirement for more than one
good ARPAnet software support person. There are persistant
rumors that Greg Noel down at NOSC may be working on a VDH
driver for 4.1a, but if he gives up, noone would blame him. The best
thing to do, if your IMP must be remote from you, is to get a pair
of ECU-II's from ACC. The Error Control Units connect to modems
between the pair, and to the host, it looks like a local IMP interface,
and to the IMP, it looks like a local host interface. ECU's are not
perfect, and if you have a really rotten phone line between them,
you will have grief, but not nearly as much as with a VDH. The other
alternative would be to do an HDH driver, which would actually be
doing the world a large service. But I am somewhat curious about
your comment about "do I really need a C30?" If you don't
have one, who does?? I have been assuming from your questions that
you will be remote from some other IMP. Somewhere the must be an IMP
HOST PORT to which your machine is attached.
-Mike
------------------------------
Date: Wednesday, 8 Sep 1982 10:29-PDT
From: obrien at Rand-Unix
To: Mark Weiser <mark.umcp-cs@Udel-Relay>
Cc: unix-wizards at Sri-Csl, tcp-ip at Mit-Ai
Subject: Re: Very Distant Host support under 4.1bsd Unix.
I have never actually attempted to run VDH, but everyone I've ever
talked to has been very negative about the experience. It is apparently
extremely difficult to get the software exactly right for checksumming, etc.
the packets from the IMP, and the link is very, very slow.
If your phone Co. is good you might try running a local host
interface using ACC ECU boxes, which shove 1822 over a phone line using
SDLC. These let you run a local/distant host interface over miles and miles
of phone line, if your IMP actually has room in it for a local/distant
interface. Our own experience in this department has not been sterling,
because we have General Telephone here. The link to Rand-Relay is an ECU
link over a leased line to an IMP four or five miles away. This link worked
just fine until the Rixon-Sangamo T209 modem on the other end blew up, and
it hasn't been right since. Our new C-30 eliminates our need for this link.
It seems to be a little-known fact that on a Honeywell TIP, the TIP
hardware takes up so much rack space that the fourth hookup to the IMP MUST
be a VDH. On C-30's this restriction has been removed. That was our
situation and is the reason we chose to run with ECU's to an IMP miles away,
rather than attempting to run VDH for 50 feet. After Gen. Tel. I'm not sure
which alternative was worse.
------------------------------
Date: 10 Sep 1982 01:32:33-PDT
From: CCVAX.ron at Nosc-Cc
To: mark.umcp-cs at Udel-Relay, mo at Lbl-Unix
Subject: Re: Very Distant Host support under 4.1bsd Unix.
Cc: tcp-ip at Mit-Ai, unix-wizards at Sri-Csl
The "persistent rumors that Greg Noel down at NOSC may be working on a VDH
driver for 4.1a" are no longer valid. Greg quit NPRDC a few weeks ago
and the VDH project is now dead. The day after he quit his management
scrambled for the $$$ to buy an LHDH and a pair of ECUs.
--Ron
------------------------------
Date: 10 Sep 1982 1207-PDT
From: DEDWARDS at Usc-Isi
Subject: Re: Very Distant Host support under 4.1bsd Unix.
To: mark.umcp-cs at Udel-Relay, unix-wizards at Sri-Csl
cc: tcp-ip at Mit-Ai
Don't know about the VDH support, but you do NOT need a c/30.
You can use a pair of ECU's to go the long haul and they allow you
to look like a local host (ECU's are built by ACC).
Howard Weiss
------------------------------
Date: 23 Aug 1982 at 1020 Pacific Daylight Time
From: wss at Lll-Unix (Walter Scott - Consultant/SC)
Subject: Berkeley TCP/IP on 2.8bsd at SRI?
To: tcp-ip at BRL
Cc: gp kawin at lll-unix
A few months ago, I remember reading on this mailing list that
some folks at SRI were attempting to port the Berkeley TCP/IP
code to 2.8 bsd on an 11/70. What's the story now? Was it
successful? Is it available? Has anybody else tried to do
something similar?
I guess what I really want to know is whether anybody has TCP/IP
working under 2.8bsd.
Thanks,
Walter Scott
[ The SRI project to integrate the 4.1a code into 2.8 is well underway.
I'm sure we will be hearing a status report soon. -Mike ]
------------------------------
Date: 17 Jun 1982 1242-PDT
From: PADLIPSKY at Usc-Isi
Subject: A Possibly Old Question
To: tcp-ip at BRL
It's probably come up before, but I haven't been saving
back Digests, so with apologies for redundancy can anybody
tell me what the state of availability of TCP/IP (and even
process-level protocols) is for PWB UNIXtm (Version 6,
I think).
Thanks
and cheers,
map
------------------------------
Date: 22 Jul 1982 1722-PDT
From: Johnson at Sumex-Aim
Subject: Cray TCP/IP
To: tcp-ip at BRL
cc: samuelson at Sandia
TCP/IP implementation is not available for Cray. CRI (Cray Research
Inc.) has been gathering data on what protocols they will need to
support in the future. I suggested that since the government is
a large customer of theirs, they should consider TCP/IP support.
They were not familiar with the protocol. They are, however,
interested in Cray user response, so I suggest you contact:
Derek Robb
CRI
1440 N. Land Road
Mendota Heights, MN 55120
800-328-0248
(In fact, if anything will move them toward support, demand from
current, or prospective, Cray owners will do it.)
--Suzanne Johnson
------------------------------
Date: 24 Jul 82 23:47:21-EDT (Sat)
From: J. C. Pistritto <jcp@brl-bmd>
To: tcp-ip at Brl-Bmd
Subject: TCP-IP for Intel MDS?
Does anyone know of a TCP-IP implementation being done for any of the
Intel MDS-240 series processors? These are the 8086 development systems
that Intel markets. An implementation using either the 3Com or Interlan
Ethernet boards would be of interest. On the subject of which, does
anyone have experience/comments on using these on a PDP-11 series
processor, (not VAX)?
-JCP-
------------------------------
Date: 5 Aug 82 19:19:08-EDT (Thu)
From: Doug Kingston <dpk@BRL>
To: tcp-ip at BRL
Subject: TCP/IP for hard cases
This is an inquiry for a third party...
TCP/IP for the following machines or close enough to consider
porting:
Honeywell Level 6 running GECOS
IBM 30xx (3033?) running MVS
Sigh.
-Doug-
------------------------------
Date: 7 Sep 1982 1202-PDT (Tuesday)
From: yale at Nosc-Sdl (Bob Yale)
Subject: Re: tcp mailing list
To: tcp-ip at BRL
Mike,
I think I am going to have a problem getting the TCP/IP protocols
up and running. The problem is that I have a PDP 11/40 running V6
with only 80kb of memory. Do you know of anyone who has brought
a V7 system up on an 11/40?
Also what is the size of the TCP/IP code? I might able to make it
fit but if not we will have to get a new CPU. That will be a
real nightmare getting the paper work through for new ADP equipment.
Basically, my question is: How much memory will I need to bring
a V7 Unix with a TCP/IP kernel? And does Bell Labs distribute a
V7 for 11/40's?
Thanks
Bob Yale\@nosc-sdl
[ Unless you use an ENABLE/34 from Able to add more memory to your 11/40,
it will be *very* *painful* to fit UNIX plus TCP/IP in an 11/40.
You might consider running the 11/40 as a Mills FUZZBALL. -Mike ]
END OF TCP-IP DIGEST
********************