|
|
ARCHIVE: TCP-IP Distribution List - Archives (1981)
DOCUMENT: TCP-IP Distribution List for December 1981 (4 messages, 9652 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1981/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: Fri Dec 11 18:33:30 1981 From: ucbvax!tcp-ip To: fa.tcp-ip Subject: TCP-IP Digest, Vol 1 #8
>From tcp-ip@brl Fri Dec 11 18:15:56 1981
TCP/IP Digest Friday, 11 Dec 1981 Volume 1 : Issue 8
Today's Topics:
TCP/IP for CDC CYBER Mainframes
Mail Between NCP and TCP Hosts -- RFC801 Excerpts
Relating ArpaNet Protocols to the ISO Reference Model
TCP/IP Conversion Timetable & Documents -- RFC801 again
Tidbit about UK INDRA Project
----------------------------------------------------------------------
Subject: TCP/IP for CDC CYBER Mainframes
From: SITNIK at OFFICE-8
Tektronix has implemented TCP/IP on their CDC CYBER mainframe.
The project is being directed by Tim Fallon, (415) 627-5471. Tim
doesn't mind being contacted and in fact, would like to
distribute TCP to anyone who is interested with the understanding
that there is no committment of future support by Tektronix. He
is currently exploring the distribution issue with the Tektronix
legal department.
The Tektronix implementation of TCP/IP runs at a System Control
Point (SCP) under the NOS operating system. Interface with the
user is through SCP macro calls. Interface to the network is via
a Hyperchannel device drive which runs in a peripheral processor.
Tim is not aware of anyone working on a NOS/BE version of TCP.
Rich Sitnik
------------------------------
From: csk at UCLA-Security (Charley Kline)
Subject: mail among tcp/ncp hosts
A while ago, the following question was asked and I didn't see an
answer to it in this digest. Can someone answer it. Thanks.
As TCP/IP becomes the standard, many hosts are coming online with
only TCP/IP protocols. Can someone explain where and how one uses
mail gateways to get mail to/from hosts which are using NCP
protocols with those using TCP/IP protocols while the transition
is taking place?
--charley
[ I believe that the plan for transition is well detailed in RFC801,
which is availible for FTP from the NIC using account "anonymous",
and your name for the password. File is <netinfo>rfc801.txt
I have included pieces here for everybody to see. -Mike ]
------------------------------
Subject: RFC801 Excerpts about NCP <-> TCP Mail and File Transfer
Network Working Group J. Postel
Request for Comments: 801 ISI
For FTP, there will be provided one or more relay hosts. An FTP
relay host will implement both the NCP and TCP environments, both
user and server Telnet, and both user and server FTP in both
environments. Users requiring FTP service between hosts in
different environments will first connect via Telnet to an FTP
relay host, then use FTP to move the file from the file donor host
to the FTP relay host, and finally use FTP to move the file from
the FTP relay host to the file acceptor host. (See Appendix B.)
For Mail, hosts will implement the new Simple Mail Transfer
Protocol (SMTP) described in RFC 788. The SMTP procedure provides
for relaying mail among several protocol environments. For
TCP-only hosts, using SMTP will be sufficient. For NCP-only hosts
that have not been modified to use SMTP, the special syntax
"user.host@forwarder" may be used to relay mail via one or more
special forwarding host. Several mail relay hosts will relay mail
via SMTP procedures between the NCP and TCP environments, and at
least one special forwarding host will be provided.
------------------------------
From: Michael Muuss <mike@brl>
Subject: Relating ArpaNet Protocols to the ISO Reference Model
Whilst reading a copy of "FY80 Final Report: Cable Bus Applications
in Command Centers" from the Mitre Corporation which was kindly provided
to me by Steve Holmgren <Steve@Mitre>, I discovered a most interesting
comparison between the TCP/IP based ArpaNet, and the ISO Reference Model.
Included is basically the following picture:
ISO Reference Model | ArpaNet Environment
------------------------|-------------------------------------
Application |
------------------------|
Presentation | Virtual Terminal Protocol
------------------------|
Session |-------------------------------------
------------------------|
Transport | Transmission Control Protocol/
------------------------| InterNet Protocol
Network |-------------------------------------
------------------------|
Data-Link Cntrl | Variety of Low-Level Network
------------------------| Access Mechanisms
Physical |
------------------------|-------------------------------------
Also there is the following descriptive text:
"At the lower protocol levels there is no natural intersection of the
DARPA-like architectures with the ISO Reference Model (RM), but
above layer four in the RM and the end-to-end transport layer in
the DARPA model an eventual mergins of models is possible.
TCP contains some session layer mechanisms and our Virtual Terminal
Protocol (VTP) contains both session and presentation functions, but
the splitting out of these functions in the VTP model is possible and
would not significantly change the protocol itself. Naturally, a VTP
that fits within the open systems architecture would need to utilize
certain data transformation services of the presentation layer and data
transfer controlling services of the session layer. This could be done
by using appropriately constructed presentation and session protocols."
[pp 17-19]
------------------------------
From: Michael Muuss <mike@brl>
Subject: TCP-IP Conversion Timetable & Documents, from RFC801
RFC 801 November 1981
NCP/TCP Transition Plan
Milestones When
---------- ----
First Internet Service already
A few hosts are TCP-capable and use TCP-based services.
First TCP-only Host already
The first TCP-only host begins use of TCP-based services.
Telnet and FTP Relay Service already
Special relay accounts are available to qualified users with a
demonstrated need for the Telnet or FTP relay service.
Ad Hoc Mail Relay Service already
An ad hoc mail relay service using the prototype MTP (RFC 780) is
implemented and mail is relayed from the TCP-only hosts to
NCP-only hosts, but not vice versa. This service will be replaced
by the SMTP service.
Last NCP Conversion Begins Jan 82
The last NCP-only host begins conversion to TCP.
Mail Relay Service Jan 82
The SMTP (RFC 788) mail service begins to operate and at least one
mail relay host is operational, and at least one special forwarder
is operational to provide NCP-only host to TCP-only host mail
connectivity.
Normal Internet Service Jul 82
Most hosts are TCP-capable and use TCP-based services.
Last NCP Conversion Completed Nov 82
The last NCP-only host completes conversion to TCP.
Full Internet Service Jan 83
All hosts are TCP-capable and use TCP-based services. NCP is
removed from service, relay services end, all services are
TCP-based.
Documents
---------
The following RFCs document the protocols to be implemented in the
new IP/TCP environment:
IP RFC 791
ICMP RFC 792
TCP RFC 793
Telnet RFC 764
FTP RFC 765
SMTP RFC 788
Name Server IEN 116
Assigned Numbers RFC 790
These and associated documents are to be published in a notebook, and
other information useful to implementers is to be gathered. These
documents will be made available on the following schedule:
Internet Protocol Handbook Jan 82
Implementers Hints Jan 82
SDC IP/TCP Specifications Jan 82
Expanded Host Table Jan 82
------------------------------
From: PKIRSTEIN at USC-ISI
Subject: Re: TCP-IP Digest, Vol 1 #6
In response to your message sent 18 Nov 81 5:39:59-EDT (Wed)
Mike,
There is a lot of things one can say about the INDRA project. What level, and
what length interests you. The project has been going in some form for
eight years, and we are deeply involved in providing services for UK groups
to have terminal, file and mail connectiviity with US groups who are
both on ARPANET or TElENET in the US, and on SRCNET or PSS in the UK. Thus
the project is like CSNET, but also as a considerable research congent.
We are active in various Internet and satelite projects as well.
Peter Kirstein
END OF TCP-IP DIGEST
********************
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 81 18:53:15-EST (Fri) From: Mike Muuss <tcp-ip@brl> To: list: Subject: TCP-IP Digest, Vol 1 #8
TCP/IP Digest Friday, 11 Dec 1981 Volume 1 : Issue 8
Today's Topics:
TCP/IP for CDC CYBER Mainframes
Mail Between NCP and TCP Hosts -- RFC801 Excerpts
Relating ArpaNet Protocols to the ISO Reference Model
TCP/IP Conversion Timetable & Documents -- RFC801 again
Tidbit about UK INDRA Project
----------------------------------------------------------------------
Subject: TCP/IP for CDC CYBER Mainframes
From: SITNIK at OFFICE-8
Tektronix has implemented TCP/IP on their CDC CYBER mainframe.
The project is being directed by Tim Fallon, (415) 627-5471. Tim
doesn't mind being contacted and in fact, would like to
distribute TCP to anyone who is interested with the understanding
that there is no committment of future support by Tektronix. He
is currently exploring the distribution issue with the Tektronix
legal department.
The Tektronix implementation of TCP/IP runs at a System Control
Point (SCP) under the NOS operating system. Interface with the
user is through SCP macro calls. Interface to the network is via
a Hyperchannel device drive which runs in a peripheral processor.
Tim is not aware of anyone working on a NOS/BE version of TCP.
Rich Sitnik
------------------------------
From: csk at UCLA-Security (Charley Kline)
Subject: mail among tcp/ncp hosts
A while ago, the following question was asked and I didn't see an
answer to it in this digest. Can someone answer it. Thanks.
As TCP/IP becomes the standard, many hosts are coming online with
only TCP/IP protocols. Can someone explain where and how one uses
mail gateways to get mail to/from hosts which are using NCP
protocols with those using TCP/IP protocols while the transition
is taking place?
--charley
[ I believe that the plan for transition is well detailed in RFC801,
which is availible for FTP from the NIC using account "anonymous",
and your name for the password. File is <netinfo>rfc801.txt
I have included pieces here for everybody to see. -Mike ]
------------------------------
Subject: RFC801 Excerpts about NCP <-> TCP Mail and File Transfer
Network Working Group J. Postel
Request for Comments: 801 ISI
For FTP, there will be provided one or more relay hosts. An FTP
relay host will implement both the NCP and TCP environments, both
user and server Telnet, and both user and server FTP in both
environments. Users requiring FTP service between hosts in
different environments will first connect via Telnet to an FTP
relay host, then use FTP to move the file from the file donor host
to the FTP relay host, and finally use FTP to move the file from
the FTP relay host to the file acceptor host. (See Appendix B.)
For Mail, hosts will implement the new Simple Mail Transfer
Protocol (SMTP) described in RFC 788. The SMTP procedure provides
for relaying mail among several protocol environments. For
TCP-only hosts, using SMTP will be sufficient. For NCP-only hosts
that have not been modified to use SMTP, the special syntax
"user.host@forwarder" may be used to relay mail via one or more
special forwarding host. Several mail relay hosts will relay mail
via SMTP procedures between the NCP and TCP environments, and at
least one special forwarding host will be provided.
------------------------------
From: Michael Muuss <mike@brl>
Subject: Relating ArpaNet Protocols to the ISO Reference Model
Whilst reading a copy of "FY80 Final Report: Cable Bus Applications
in Command Centers" from the Mitre Corporation which was kindly provided
to me by Steve Holmgren <Steve@Mitre>, I discovered a most interesting
comparison between the TCP/IP based ArpaNet, and the ISO Reference Model.
Included is basically the following picture:
ISO Reference Model | ArpaNet Environment
------------------------|-------------------------------------
Application |
------------------------|
Presentation | Virtual Terminal Protocol
------------------------|
Session |-------------------------------------
------------------------|
Transport | Transmission Control Protocol/
------------------------| InterNet Protocol
Network |-------------------------------------
------------------------|
Data-Link Cntrl | Variety of Low-Level Network
------------------------| Access Mechanisms
Physical |
------------------------|-------------------------------------
Also there is the following descriptive text:
"At the lower protocol levels there is no natural intersection of the
DARPA-like architectures with the ISO Reference Model (RM), but
above layer four in the RM and the end-to-end transport layer in
the DARPA model an eventual mergins of models is possible.
TCP contains some session layer mechanisms and our Virtual Terminal
Protocol (VTP) contains both session and presentation functions, but
the splitting out of these functions in the VTP model is possible and
would not significantly change the protocol itself. Naturally, a VTP
that fits within the open systems architecture would need to utilize
certain data transformation services of the presentation layer and data
transfer controlling services of the session layer. This could be done
by using appropriately constructed presentation and session protocols."
[pp 17-19]
------------------------------
From: Michael Muuss <mike@brl>
Subject: TCP-IP Conversion Timetable & Documents, from RFC801
RFC 801 November 1981
NCP/TCP Transition Plan
Milestones When
---------- ----
First Internet Service already
A few hosts are TCP-capable and use TCP-based services.
First TCP-only Host already
The first TCP-only host begins use of TCP-based services.
Telnet and FTP Relay Service already
Special relay accounts are available to qualified users with a
demonstrated need for the Telnet or FTP relay service.
Ad Hoc Mail Relay Service already
An ad hoc mail relay service using the prototype MTP (RFC 780) is
implemented and mail is relayed from the TCP-only hosts to
NCP-only hosts, but not vice versa. This service will be replaced
by the SMTP service.
Last NCP Conversion Begins Jan 82
The last NCP-only host begins conversion to TCP.
Mail Relay Service Jan 82
The SMTP (RFC 788) mail service begins to operate and at least one
mail relay host is operational, and at least one special forwarder
is operational to provide NCP-only host to TCP-only host mail
connectivity.
Normal Internet Service Jul 82
Most hosts are TCP-capable and use TCP-based services.
Last NCP Conversion Completed Nov 82
The last NCP-only host completes conversion to TCP.
Full Internet Service Jan 83
All hosts are TCP-capable and use TCP-based services. NCP is
removed from service, relay services end, all services are
TCP-based.
Documents
---------
The following RFCs document the protocols to be implemented in the
new IP/TCP environment:
IP RFC 791
ICMP RFC 792
TCP RFC 793
Telnet RFC 764
FTP RFC 765
SMTP RFC 788
Name Server IEN 116
Assigned Numbers RFC 790
These and associated documents are to be published in a notebook, and
other information useful to implementers is to be gathered. These
documents will be made available on the following schedule:
Internet Protocol Handbook Jan 82
Implementers Hints Jan 82
SDC IP/TCP Specifications Jan 82
Expanded Host Table Jan 82
------------------------------
From: PKIRSTEIN at USC-ISI
Subject: Re: TCP-IP Digest, Vol 1 #6
In response to your message sent 18 Nov 81 5:39:59-EDT (Wed)
Mike,
There is a lot of things one can say about the INDRA project. What level, and
what length interests you. The project has been going in some form for
eight years, and we are deeply involved in providing services for UK groups
to have terminal, file and mail connectiviity with US groups who are
both on ARPANET or TElENET in the US, and on SRCNET or PSS in the UK. Thus
the project is like CSNET, but also as a considerable research congent.
We are active in various Internet and satelite projects as well.
Peter Kirstein
END OF TCP-IP DIGEST
********************
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 23 Dec 81 21:55:24-EST (Wed) From: Mike Muuss <tcp-ip@brl> To: list: Subject: TCP-IP Digest, Vol 1 #9
TCP/IP Digest Wednesday, 23 Dec 1981 Volume 1 : Issue 9
Today's Topics:
ComputerWorld TCP Article && Packet Radio IP Woes
TCP-IP Implementations for TOPS-10? && BBN VAX TCP/IP Status Report
TCP/IP Pronet Device Drivers for 4.1BSD && November Internet Report:
Summary, VAX & C70 TCP, HP3000, TAC Operational, SATNET, GATEWAYs
TOPS-20 TCP/IP Performance Measurements
----------------------------------------------------------------------
From: Raleigh F Romine <romine@SRC-Unix>
Subject: ComputerWorld TCP Article
Mike,
The 14 Dec issue of ComputerWorld has an interesting
article on the ARPAnet TCP/IP cutover and it's commercial
impact. It might be of interest to TCP-IP Digest readers.
Raleigh
------------------------------
From: WOHL at CMU-20C
Subject: Why use user.host@forwarder ?
The proposed syntax of mailboxes for NCP to TCP forwarders
(see rfc801 pg 15) is user.host@forwader. Since tops-20
user names can have dots in them this new syntax would make
the parsing of mailboxes ambigous. The mailbox foo.xx@cmuc
could mean user foo on xx via cmuc or user foo.xx on cmuc.
The choice to overload the use of the dot would prevent
the many tops-20 sites from acting as relay hosts.
Why move away from the rfc733 idea that dot is part of a
username?
Aaron
------------------------------
From: John C. Gilmore <GNU at MIT-AI>
Please add me to the list "tcp-ip". I'm doing packet radio Internet
design and are having (what seems the usual) problems with Internet --
the addresses are too short (24 bits within network, requiring central
authority passing them out).
What we're plainning on, at the moment, is using those 24 bits to encode the
latitude and longitude to within a 1 degree-per-side rectangle, and add new
required "Option" fields containing the real addresses. Is there a better
approach short of junking Internet?
------------------------------
From: STECKEL at HARV-10
Subject: TCP-IP Implementations for TOPS-10
Sirs -
As the entire staff of HARV-10, an ARPAnet site running a DEC PDP-10
under the TOPS-10 monitor, I am wondering if any other TOPS-10 site is
considering writing the conversion code. If not, I would like to know
what document describes the exact method for sending an IP message via
the "1822" interface (BBN report describing IMP-HOST messages).
regards,
Geoff Steckel (STECKEL@HARV-10)
[ The connection is mentioned in passing in RFC790, which states that all
InterNet messages are to be sent on Link 155 decimal, which is currently
not used for ArpaNet Host-Host Protocol. For the rest, RFCs 791, 792,
and 793 should do the trick. -Mike]
------------------------------
From: Rob Gurwitz <gurwitz at BBN-RSM>
Mike,
I'm sending you this update on the progress of our BBN VAX TCP/IP in hopes
of clearing up some misconceptions that might have formed in the community
about it. Specifically, I want to clarify notions about "the BBN TCP/IP"
(we've done many implementations at various times), about Berkeley's role
in the implementation, and about general availability of the software.
Rob
*********
BBN has developed an implementation of TCP/IP for DEC's VAX(TM) family of
processors, that runs under the Berkeley 4.1BSD version of UNIX(TM). The
development effort was funded by DARPA.
BBN has been involved in the development of TCP/IP from its earliest stages,
and was responsible for some of the first experimental implementations
for TOPS20 and PDP-11s running UNIX. The VAX TCP/IP, along with TCPs for
the HP 3000 and the BBN C/30 Terminal Access Controller, is one of several
"second generation" implementations being produced at BBN, and is intended
for production use. The VAX TCP/IP implementation has also been ported to
the BBNCC C/70, which runs UNIX Version 7.
Some important features of the BBN VAX TCP/IP are that it runs in the UNIX
kernel for enhanced performance, it is a complete implementation of the TCP
and IP protocols, and provides facilities for direct user access to the IP
and underlying network protocols.
Performance measurements indicate BBN VAX TCP/IP data throughput to be in
excess of 120K bits/second over an ARPANET interface. Work is currently
underway in cooperation with the Berkeley Computer Science Research Group
to enhance BBN VAX TCP/IP performance over high speed local area networks.
Preliminary studies have measured throughputs in excess of 1.25M
bits/second with a prototype ETHERNET.
In addition to the TCP/IP software for the VAX, BBN has developed
implementations of the TELNET Virtual Terminal Protocol, File Transfer Protocol
(FTP), and Mail Transfer Protocol (MTP), for use with TCP. The BBN VAX TCP/IP
will support a variety of high speed local area network interfaces, as well
as ARPANET interfaces. The software is in beta-test at several sites
around the country, and will be generally available direct from BBN in
Spring, 1982, or through Berkeley in their next software distribution.
------------------------------
From: tjt at mit-vax at mit-xx
Subject: pronet device drivers
We (MIT Laboratory for Computer Science) are working on such a driver
to work with the BBN TCP/IP that runs under 4.1BSD in loose
collobaration with Rob Gurwitz of BBN (they also have some Pronet
boards). We hope to get something usable within a week or so, but
also expect to have some minor difficulty scheduling debugging time
on our machine (hence 1-2 weeks rather than 1-2 days).
------------------------------
From: Mike Muuss <tcp-ip@BRL>
One of the folks at Utah forwarded me the "November Internet Report"
and suggested that I extract portions of general interest and send
them to the whole list. Undoubtably, some of you will have seen this
before, so you can just ignore the next 150 lines.
------------------------------
From: Dave Clark (DClark @MIT-Multics)
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, TCP/IP Summary
TCP/IP continues to get more visibility, including a recent
Computerworld story that reported some of the good performance
results from the VAX software. Attention in the performance
area is really important.
The performance results that the TOPS-20 study produced are
typical of other such investigations. One always hopes that
there is one really awful place where a fix will have a
wonderful result, but such is never the case. The time just
gets used up everywhere. The TOPS-20 study also identified a
problem that, in my opinion, will be the most important
performance issue: the sending of unnecessary packets. Most
implementations have processing times that relate to number of
packets, and not to the number of bits sent. This being so,
sending half as many packets for the same data cuts the
processing time in half. There are few other places where one
can get this kind of improvement in one move. I have a chapter
of my implementor's guide that discusses how to send fewer
packets. Anyone wanting a early draft (cost: your comments
back) should let me know.
Now that the SMTP specification is out, people should think
about getting it implemented, if they have not already done
so. The mail aspect of conversion to TCP has many parts to it,
and we must make steady progress here to avoid missing
deadlines.
------------------------------
From: Bob Hinden
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, BBN COMMUNICATIONS SYSTEMS DIVISION
VAX and C70 TCP
Testing, bug fixing, and performance analysis continued on
the VAX TCP. The software was sent to Berkeley, CMU, ISI,
Purdue (CSNET), Stanford, and MIT LCS. BBN-VAX is running
multi-homed on the ARPANET and the RCCNET. Things seem to
be working fine, and we are providing good service to users
on both nets. Work is continuing on defining and enhancing
the raw IP and local net user interfaces. We will be
merging in the Berkeley performance improvements for high
speed local net use in the near future.
On the C70 front, we have a TCP running on a NCP/TCP host.
The software is performing well enough to put into
production. We are still working on tuning the TCP for the
C70's smaller buffer complement, with good success. We
expect to be providing TCP service to the BBN Unix Cost
Center C70s (at least 8 machines), including NCP/TCP mail
forwarding, in the coming month.
HP3000
We are currently working on a raw datagram user interface.
The interface will be implemented with user intrinsics
similar to the TCP intrinsics previously implemented. Once
the Interface has been implemented and tested, we will
build an Internet name server. Watch this space next month
for an invitation to try our Internet name server.
TAC
The first operational TAC in the Arpanet was installed at
CCA. After a few problems the first day, it now seems quite
stable. It has been up since November 24.
SATNET
We installed a C/30 Satellite IMP at COMSAT Laboratories in
Clarksburg, Maryland, the first time ever that a C/30 has
served as a Satellite IMP in SATNET. Connectivity between
Clarksburg and the other Satellite IMPs on SATNET through
the INTELSAT IV-A satellite remains untested, though, since
the COMSAT Unattended Earth Terminal is non-functional with
SATNET. We have established the convention that C/30
Satellite IMP version numbers begin with a 4 instead of a
3, as shown in the MONITOR reports when typing ^P.
GATEWAY
Development is continuing on the macro-11 gateways. After
GGP routing has been fully debugged, the new gateway should
be ready for installation at the first site, the RCC
gateway.
The TIU and macro-11 gateway have been successfully tested
as hosts on a V2LNI ring net. The TIU was able to pass
internet traffic through the V2LNI net to BBN-VAX on the
DIV-5 net via the macro-11 gateway.
The gateway VDH loader has become operational at NDRE. The
only way to load the NDRE gateway is via SATNET using the
VDH loader.
------------------------------
From: Charles Lynn
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, BBN INFORMATION SCIENCES DIVISION
Most of our efforts during November have been directed at
TOPS-20 TCP/IP performance. In our timing experiments, we are
employing techniques such as PC sampling, control stack
sampling, and packet tracing.
PC-sampling of the TCP/IP process has produced discouragingly
flat histograms; the highest frequency was about six percent
(checksumming).
A control stack sampling facility was then developed to
provide time breakdowns by logical function. This reveals
that most of the time is spent processing incoming packets.
The data indicates several areas where further specific
monitoring might be useful: free storage management, buffer
header usage (reuse vs allocating & deallocating both memory
and locks each time), and improvements in the decision-making
control structure for incoming packets, to be sure that the
most common cases are examined earliest.
Packet traces have revealed circumstances under which the TCP
is forced to process unnecessary ACKs and retransmissions.
For example, if the receiving user is using multiple buffers,
extra ACKs are sent which show an (insignificantly) larger
window before the transmitter has processed the previous ACK
(of data). If 3 buffers are being used, filling the first
generates an ACK for the data and passes the buffer to the
user (leaving a window of two buffers). The user then
processes the data and requests that the buffer be refilled
(increasing the window to three buffers). Another ACK for the
old data with the increased window is sent to the transmitter
which has to process an "extra" packet.
In another situation, a receiver that sends an ACK before it
has processed all of its received packets interacts adversely
with the retransmitter, which does not retransmit a packet
until the previous one has been ACKed. If the transmitter is
generating data faster than the net is processing it (or is
PUSHing) there may be several packets in the retransmission
queue. When a packet is lost (but packets after it get
through) a timeout will cause the packet to be retransmitted.
Before the ACK for the retransmitted packet can arrive, the
following packet may timeout (but is not retransmitted because
the ACK for the prior has not yet arrived). While the ACK for
the lost packet is traveling to the sender, the receiver is
processing the following packet which did get through. When
the sender gets the ACK, it then retransmits the (second)
timedout packet. Several unnecessary retransmissions may
follow until the other end can catch up.
We are also investigating another problem area that could add
significantly to the cpu-utilization of the TCP/IP: use of
1822 interfaces that transfer all 36 bits of the PDP-10 word
to/from the net, necessitating a (possibly) expensive
bit-shuffle in behalf of the 8-bit-oriented TCP. We are
presently performing experiments to determine the precise
cpu-cost of this bit-rearranging, and will publish the results
when available. If this cost proves significant AND
replacement of the interface with an AN10/20 is not possible
AND the interface can be modified to perform 32-bit transfers
(true of both flavors of BBN 1822), we will provide the
software modifications needed to converse with the modified
interface.
END OF TCP-IP DIGEST
********************
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Wed Dec 23 22:40:01 1981 From: ucbvax!tcp-ip To: fa.tcp-ip Subject: TCP-IP Digest, Vol 1 #9
>From tcp-ip@brl Wed Dec 23 22:21:05 1981
TCP/IP Digest Wednesday, 23 Dec 1981 Volume 1 : Issue 9
Today's Topics:
ComputerWorld TCP Article && Packet Radio IP Woes
TCP-IP Implementations for TOPS-10? && BBN VAX TCP/IP Status Report
TCP/IP Pronet Device Drivers for 4.1BSD && November Internet Report:
Summary, VAX & C70 TCP, HP3000, TAC Operational, SATNET, GATEWAYs
TOPS-20 TCP/IP Performance Measurements
----------------------------------------------------------------------
From: Raleigh F Romine <romine@SRC-Unix>
Subject: ComputerWorld TCP Article
Mike,
The 14 Dec issue of ComputerWorld has an interesting
article on the ARPAnet TCP/IP cutover and it's commercial
impact. It might be of interest to TCP-IP Digest readers.
Raleigh
------------------------------
From: WOHL at CMU-20C
Subject: Why use user.host@forwarder ?
The proposed syntax of mailboxes for NCP to TCP forwarders
(see rfc801 pg 15) is user.host@forwader. Since tops-20
user names can have dots in them this new syntax would make
the parsing of mailboxes ambigous. The mailbox foo.xx@cmuc
could mean user foo on xx via cmuc or user foo.xx on cmuc.
The choice to overload the use of the dot would prevent
the many tops-20 sites from acting as relay hosts.
Why move away from the rfc733 idea that dot is part of a
username?
Aaron
------------------------------
From: John C. Gilmore <GNU at MIT-AI>
Please add me to the list "tcp-ip". I'm doing packet radio Internet
design and are having (what seems the usual) problems with Internet --
the addresses are too short (24 bits within network, requiring central
authority passing them out).
What we're plainning on, at the moment, is using those 24 bits to encode the
latitude and longitude to within a 1 degree-per-side rectangle, and add new
required "Option" fields containing the real addresses. Is there a better
approach short of junking Internet?
------------------------------
From: STECKEL at HARV-10
Subject: TCP-IP Implementations for TOPS-10
Sirs -
As the entire staff of HARV-10, an ARPAnet site running a DEC PDP-10
under the TOPS-10 monitor, I am wondering if any other TOPS-10 site is
considering writing the conversion code. If not, I would like to know
what document describes the exact method for sending an IP message via
the "1822" interface (BBN report describing IMP-HOST messages).
regards,
Geoff Steckel (STECKEL@HARV-10)
[ The connection is mentioned in passing in RFC790, which states that all
InterNet messages are to be sent on Link 155 decimal, which is currently
not used for ArpaNet Host-Host Protocol. For the rest, RFCs 791, 792,
and 793 should do the trick. -Mike]
------------------------------
From: Rob Gurwitz <gurwitz at BBN-RSM>
Mike,
I'm sending you this update on the progress of our BBN VAX TCP/IP in hopes
of clearing up some misconceptions that might have formed in the community
about it. Specifically, I want to clarify notions about "the BBN TCP/IP"
(we've done many implementations at various times), about Berkeley's role
in the implementation, and about general availability of the software.
Rob
*********
BBN has developed an implementation of TCP/IP for DEC's VAX(TM) family of
processors, that runs under the Berkeley 4.1BSD version of UNIX(TM). The
development effort was funded by DARPA.
BBN has been involved in the development of TCP/IP from its earliest stages,
and was responsible for some of the first experimental implementations
for TOPS20 and PDP-11s running UNIX. The VAX TCP/IP, along with TCPs for
the HP 3000 and the BBN C/30 Terminal Access Controller, is one of several
"second generation" implementations being produced at BBN, and is intended
for production use. The VAX TCP/IP implementation has also been ported to
the BBNCC C/70, which runs UNIX Version 7.
Some important features of the BBN VAX TCP/IP are that it runs in the UNIX
kernel for enhanced performance, it is a complete implementation of the TCP
and IP protocols, and provides facilities for direct user access to the IP
and underlying network protocols.
Performance measurements indicate BBN VAX TCP/IP data throughput to be in
excess of 120K bits/second over an ARPANET interface. Work is currently
underway in cooperation with the Berkeley Computer Science Research Group
to enhance BBN VAX TCP/IP performance over high speed local area networks.
Preliminary studies have measured throughputs in excess of 1.25M
bits/second with a prototype ETHERNET.
In addition to the TCP/IP software for the VAX, BBN has developed
implementations of the TELNET Virtual Terminal Protocol, File Transfer Protocol
(FTP), and Mail Transfer Protocol (MTP), for use with TCP. The BBN VAX TCP/IP
will support a variety of high speed local area network interfaces, as well
as ARPANET interfaces. The software is in beta-test at several sites
around the country, and will be generally available direct from BBN in
Spring, 1982, or through Berkeley in their next software distribution.
------------------------------
From: tjt at mit-vax at mit-xx
Subject: pronet device drivers
We (MIT Laboratory for Computer Science) are working on such a driver
to work with the BBN TCP/IP that runs under 4.1BSD in loose
collobaration with Rob Gurwitz of BBN (they also have some Pronet
boards). We hope to get something usable within a week or so, but
also expect to have some minor difficulty scheduling debugging time
on our machine (hence 1-2 weeks rather than 1-2 days).
------------------------------
From: Mike Muuss <tcp-ip@BRL>
One of the folks at Utah forwarded me the "November Internet Report"
and suggested that I extract portions of general interest and send
them to the whole list. Undoubtably, some of you will have seen this
before, so you can just ignore the next 150 lines.
------------------------------
From: Dave Clark (DClark @MIT-Multics)
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, TCP/IP Summary
TCP/IP continues to get more visibility, including a recent
Computerworld story that reported some of the good performance
results from the VAX software. Attention in the performance
area is really important.
The performance results that the TOPS-20 study produced are
typical of other such investigations. One always hopes that
there is one really awful place where a fix will have a
wonderful result, but such is never the case. The time just
gets used up everywhere. The TOPS-20 study also identified a
problem that, in my opinion, will be the most important
performance issue: the sending of unnecessary packets. Most
implementations have processing times that relate to number of
packets, and not to the number of bits sent. This being so,
sending half as many packets for the same data cuts the
processing time in half. There are few other places where one
can get this kind of improvement in one move. I have a chapter
of my implementor's guide that discusses how to send fewer
packets. Anyone wanting a early draft (cost: your comments
back) should let me know.
Now that the SMTP specification is out, people should think
about getting it implemented, if they have not already done
so. The mail aspect of conversion to TCP has many parts to it,
and we must make steady progress here to avoid missing
deadlines.
------------------------------
From: Bob Hinden
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, BBN COMMUNICATIONS SYSTEMS DIVISION
VAX and C70 TCP
Testing, bug fixing, and performance analysis continued on
the VAX TCP. The software was sent to Berkeley, CMU, ISI,
Purdue (CSNET), Stanford, and MIT LCS. BBN-VAX is running
multi-homed on the ARPANET and the RCCNET. Things seem to
be working fine, and we are providing good service to users
on both nets. Work is continuing on defining and enhancing
the raw IP and local net user interfaces. We will be
merging in the Berkeley performance improvements for high
speed local net use in the near future.
On the C70 front, we have a TCP running on a NCP/TCP host.
The software is performing well enough to put into
production. We are still working on tuning the TCP for the
C70's smaller buffer complement, with good success. We
expect to be providing TCP service to the BBN Unix Cost
Center C70s (at least 8 machines), including NCP/TCP mail
forwarding, in the coming month.
HP3000
We are currently working on a raw datagram user interface.
The interface will be implemented with user intrinsics
similar to the TCP intrinsics previously implemented. Once
the Interface has been implemented and tested, we will
build an Internet name server. Watch this space next month
for an invitation to try our Internet name server.
TAC
The first operational TAC in the Arpanet was installed at
CCA. After a few problems the first day, it now seems quite
stable. It has been up since November 24.
SATNET
We installed a C/30 Satellite IMP at COMSAT Laboratories in
Clarksburg, Maryland, the first time ever that a C/30 has
served as a Satellite IMP in SATNET. Connectivity between
Clarksburg and the other Satellite IMPs on SATNET through
the INTELSAT IV-A satellite remains untested, though, since
the COMSAT Unattended Earth Terminal is non-functional with
SATNET. We have established the convention that C/30
Satellite IMP version numbers begin with a 4 instead of a
3, as shown in the MONITOR reports when typing ^P.
GATEWAY
Development is continuing on the macro-11 gateways. After
GGP routing has been fully debugged, the new gateway should
be ready for installation at the first site, the RCC
gateway.
The TIU and macro-11 gateway have been successfully tested
as hosts on a V2LNI ring net. The TIU was able to pass
internet traffic through the V2LNI net to BBN-VAX on the
DIV-5 net via the macro-11 gateway.
The gateway VDH loader has become operational at NDRE. The
only way to load the NDRE gateway is via SATNET using the
VDH loader.
------------------------------
From: Charles Lynn
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, BBN INFORMATION SCIENCES DIVISION
Most of our efforts during November have been directed at
TOPS-20 TCP/IP performance. In our timing experiments, we are
employing techniques such as PC sampling, control stack
sampling, and packet tracing.
PC-sampling of the TCP/IP process has produced discouragingly
flat histograms; the highest frequency was about six percent
(checksumming).
A control stack sampling facility was then developed to
provide time breakdowns by logical function. This reveals
that most of the time is spent processing incoming packets.
The data indicates several areas where further specific
monitoring might be useful: free storage management, buffer
header usage (reuse vs allocating & deallocating both memory
and locks each time), and improvements in the decision-making
control structure for incoming packets, to be sure that the
most common cases are examined earliest.
Packet traces have revealed circumstances under which the TCP
is forced to process unnecessary ACKs and retransmissions.
For example, if the receiving user is using multiple buffers,
extra ACKs are sent which show an (insignificantly) larger
window before the transmitter has processed the previous ACK
(of data). If 3 buffers are being used, filling the first
generates an ACK for the data and passes the buffer to the
user (leaving a window of two buffers). The user then
processes the data and requests that the buffer be refilled
(increasing the window to three buffers). Another ACK for the
old data with the increased window is sent to the transmitter
which has to process an "extra" packet.
In another situation, a receiver that sends an ACK before it
has processed all of its received packets interacts adversely
with the retransmitter, which does not retransmit a packet
until the previous one has been ACKed. If the transmitter is
generating data faster than the net is processing it (or is
PUSHing) there may be several packets in the retransmission
queue. When a packet is lost (but packets after it get
through) a timeout will cause the packet to be retransmitted.
Before the ACK for the retransmitted packet can arrive, the
following packet may timeout (but is not retransmitted because
the ACK for the prior has not yet arrived). While the ACK for
the lost packet is traveling to the sender, the receiver is
processing the following packet which did get through. When
the sender gets the ACK, it then retransmits the (second)
timedout packet. Several unnecessary retransmissions may
follow until the other end can catch up.
We are also investigating another problem area that could add
significantly to the cpu-utilization of the TCP/IP: use of
1822 interfaces that transfer all 36 bits of the PDP-10 word
to/from the net, necessitating a (possibly) expensive
bit-shuffle in behalf of the 8-bit-oriented TCP. We are
presently performing experiments to determine the precise
cpu-cost of this bit-rearranging, and will publish the results
when available. If this cost proves significant AND
replacement of the interface with an AN10/20 is not possible
AND the interface can be modified to perform 32-bit transfers
(true of both flavors of BBN 1822), we will provide the
software modifications needed to converse with the modified
interface.
END OF TCP-IP DIGEST
********************
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |