J. Postel
IEN 175 ISI
13 March 1981
Internet Meeting Notes -- 28-29-30 January 1981
I. WELCOME
The meeting was held at USC Information Sciences Institute. The host
was Jon Postel. Jon opened the meeting and gave the usual
explanations about the arrangements.
Vint Cerf extended the welcome and called special attention to the
participation of representatives from CSNET, Canada, and Germany.
II. OBJECTIVES
Vint Cerf described the main objective of the meeting to be to put
issues on the table. Problems could be resolved by subsequent
arrangements between ARPA and the contractors. In particular, the
topics of performance, addressing, and documentation are of special
interest.
III. STATUS REPORTS
A. UCLA
Charley Kline gave a report on the activities at UCLA. Bob Braden
from the UCLA Computer Center is on a one year visit to UCL.
Charley is involved in a research project in the Computer Science
Department. This report is about the work Charley is involved in.
UCLA is building a system called LOCUS. It is based on Unix and a
ring network. The ringnet hardware is the LNI developed by UCI
and modified by MIT. A UCLA developed private protocol is used on
the ring. The current work is on the distributed operating
system. The goal is for the users of the system and for remote
hosts to see the collection of hosts and the ring net as one
system. The most recent effort is on file system aspects. Very
good results have been obtained yielding essentially equal access
times for local and remote files.
B. UCL
Peter Kirstein gave most of the presentation with some help from
Ron Jones. Peter noted that with Bob Braden visiting at UCL use
of the UCLA 3033 from London has increased and the service is
Postel [Page 1]
IEN 175
Internet Meeting Notes
quite good. However, he has observed random outages of line 77
lasting 5 to 15 minutes several times per week. Bob has installed
echo servers both at the TCP and IP levels at UCLA for use with
UCL measurements and tests. Peter described UCL's work on: (1) a
protocol converter for service between SATNET and SRCNET for
terminal access, SRCNET is an X.25 network; (2) a cambridge ring
at UCL where terminal access is now working via UMCZ80 interfaces;
(3) a local message system is up on the UCL Unix using the MMDF
system developed by Dave Crocker; (4) the NIFTP will be upgraded
to match the latest document; and (5) UCL has worked over the TIU
TCP and made some parameter changes and installed a dynamic
retransmission timeout procedure, also MOS was revised, and a
document is available on this.
C. RSRE
John Laws gave the RSRE report.
Gateway Status: The line between the UCL gateway and the RSRE
gateway, known as net 35, was upgraded from 4.8Kb/s to 9.6Kb/s in
November 1980. The gateway machine is still an LSI-11. Local
performance measurements on the gateway were instrumented by
writing a process timer for the MOS system which showed how long
and how often individual processes ran for and the total time
spent idling in the scheduler. These measurements showed that the
gateway did handle 50Kb/s lines and would give the expected
throughput on these lines for large data packets ( >128 user data
bytes). The switching capability was 50 packets per second using
the RSRE line cards. The time taken to switch packets from one
interface to another was 4.8msecs. This includes use of hashing
tables to determine the route of the packets. Although
fragmentation has been implemented and tested as reported at the
last meeting no use has yet been made of this facility. Source
routing code awaits a final imprimatur of the doctrine to be
employed.
Service Availability: A comparison between ARPANET availability
from the PPSN for one month periods before the last meeting and
this meeting show that although the outages total a similar total
time the ones for the Nov-Dec 80 period are mostly due to
developments in the UCL gateway rather than to SATNET as was the
case for the Aug-Sep 80 period. Two points are worth noting: (1)
Some of the longer outages were due to debuging sessions on the
UCL gateway. These are difficult because they require personnel
at RSRE, UCL and BBN to be available simultaneously. They often
require loading software at the RSRE gateway for the tests and
reloading software after the tests. (2) The large number of short
outages were traced to resetting of the Host-SIMP interface by the
Postel [Page 2]
IEN 175
Internet Meeting Notes
UCL gateway caused by shortage of buffers. Ginny alleviated this
to a large extent in January by removing code from the gateway.
However if UCL and RSRE are heavily using the gateway we can still
get up to 20 resets a day.
Local Network Status: The PPSN (net 25) now has three network
access protocols available to users, these are datagram type (with
multi-address), virtual call (PPSN type with multi-address), and
X.25 virtual call. We have developed a flexible evaluation host
both for use on the PPSN and the British Post Office PSS network
which we hope to be connected to in February. This evaluation
host supports 2 DTEs and includes a command console for setting up
multiple calls from one terminal, traffic generators, and a
measurement package. The protocols employed are the Network
Independent Transport Service (NITS) [formerly "Yellow Book"], and
X.25 level 3 with BPO options and the RSRE X.25 level 2 line
units.
TCP and IP: The CORAL implementation of IP with fragmentation and
reassembly is complete. The design for the CORAL TCP including
full state machine representation is complete and coding is in
progress. We have obviously gained a lot of useful experience for
this from using the Mathis TCP. Besides TCP measurements we now
have the capability to perform measurements of IP using echoers on
ISIE and EDN Unix as well as GGP echo packets. The IP
measurements package has the capability to make single round trip
measurements at a user settable protocol type, packet length, and
packet rate of 1 to 50 packets per second.
Action Items from RSRE:
1. Dynamic timeouts for retransmission.
2. Flag bit for copied options in IP fragments.
3. Specification for strict source routing.
4. Standard addresses for Echo, Discard, and
Character Generator servers.
5. Techniques for preventing silly window syndrome
(name due to Dave Clark).
6. No changes to addressing for a while.
Postel [Page 3]
IEN 175
Internet Meeting Notes
D. SRI
Holly Nelson reported that the TIU with fragmentation and
reassembly is in progress, that a new version of the port expander
program was delivered, that a measurement host being installed is
version 7 Unix with IP separate from TCP, and that Ron Kunzelman
will be leaving SRI in mid February.
E. NDRE
Yngvar Lundh reported that progress at NDRE continues to be
hampered by the lack of people. In spite of this, progress is
being made and speech now runs in the local net. Paal Spilling
has returned to NDRE after a one year visit to SRI. Paal will be
trying speech experiments with Lincoln.
The agreement with the Norwegian Telecommunications Authority is
being renegotiated for 2-3 years. NDRE has had discussions with
the German group.
Action Items from NDRE:
1. A HDLC port on the SATNET gateway is needed.
2. ARPANET availability must be improved.
F. MITRE
Anita Skelton discussed the development by MITRE of a Z8000 based
TCP. The program is written in C and cross compiled on Unix. The
system is a modified C MOS. The TCP is about 600 lines of C code.
This TCP has been tested talking to itself, but not against any
other TCP. The data rate measured is 350 Kb/sec. Later in the
meeting Steve Holmgren gave a presentation on this.
G. MIT
Dave Clark described developments at MIT. Planning for a computer
network architecture at MIT is being formulated in terms of a
system involving 52 buildings and 10,000 hosts. As Dave noted, he
reported again that the version 2 ring net (10 Mb/s) is almost
working. The development is a joint project with PROTEON. Some
interfaces are prototyped in multiwire. The use of IP and TFTP
based services is spreading. A Unix on the CHAOS net uses IP to
communicate with a Unix on the Ring net. Fragmentation and
Reassembly is used widely in the MIT environment. MIT did its own
reworking of MOS -- this time to make it easy to bind with
programs from other source languages.
Postel [Page 4]
IEN 175
Internet Meeting Notes
On the multics front Dave reports that IP/TCP was used over a HASP
connection on a 9.6 Kb/s line between Cambridge and Phoenix with a
round trip time of 8 seconds. Various investigations suggest
hosts should be careful about also being gateways, for example,
the gateway echo traffic could be more than the host could handle.
In one experiment a routing loop was detected and datagrams would
have looped forever except for Multics decrementing the time to
live. Multics is being connected to TYMNET and TELENET, initially
as a server for remote terminal access. A NIFTP server is being
developed, and a MTP server is up on both NCP and TCP for RFC 772
style mail.
The TOPS20 system, MIT-XX, still has trouble with the IP
implementation crashing the system, and the performance is poor
otherwise.
Dave put together a minimal IP/TCP/Telnet in BCPL for an Alto.
The total package is about 3000 words of code.
The Swallow Distributed Computing Project is basing its
communication primitives on IP/UDP. A C-30 IMP is scheduled for
delivery to MIT in early February.
Action Items from MIT:
1. A maximum segment size TCP option is needed.
H. Lincoln Laboratory
Jim Forgie described the work Lincoln has done on the Voice
Terminal (VT) and the ST Gateway. Several VTs now exist and are
functioning on the LEXNET. Two modes of speech data are supported
64Kb/s PCM and 2.4Kb/s LPC. A ST gateway is partially implemented
in an 11/45 running EPOS and experiments are being done via the
ARPANET with ISI. The gateway currently supports only the
point-to-point ports of the ST protocol (no conference support
yet). The measured gateway throughput is about 100
packets/second. The next few milestones on the Lincoln schedule
are:
1. Move the gateway from the 11/45 to the 11/44.
2. Demo speech over the WBCNET.
3. Deliver a LEXNET and VTs to ISI.
4. Add source routing to ST and the gateway.
Postel [Page 5]
IEN 175
Internet Meeting Notes
5. Add conferencing features.
I. Linkabit
Estil Hoversten discussed Linkabit's role in the support for
SATNET and WBCNET. Linkabit provides clever modems to make the
most of the channel. Estil pointed out that when Germany and
Italy join the SATNET the channel will be more shared and less
capacity will be available to existing communication partners.
For the WBCNET Estil reviewed the state of installation. All the
equipment is in place at ISI and LL, but the RF and power
equipment needs tuning up. The DCEC and SRI equipment should be
fully in place before the next IN MTG. Something called "Remote
Control and Alarming" is needed to make the operation legal. The
FCC requires that an operator (FCC licensed) be able to control
the transmitter (shut it off) if something goes wrong. Western
Union is installing the remote control mechanism so their operator
in New Jersey can satisfy this requirement.
Estil also mentioned that Linkabit has some communication between
two sites in San Diego several miles apart to support terminal
access for terminals at one site to TOPS20s at the other site.
They use dumb multiplexors and a 45 Mb/s microwave link. Also
Linkabit is part of M/A-COM which is planning to link its four
major sites via a satellite channel in the 800 Kb/s to Mb/s range.
J. ISI
Jon Postel reported on the activities at ISI. The Internet
Project has three areas of interest: Protocol Verification,
Protocol Design, and Protocol Applications. In the verification
area Carl Sunshine made a presentation later in the meeting. In
the design area Danny Cohen has led our efforts primarily in
discussion of addressing issues (see IEN 165). In the application
area we are developing two computer mail applications: the MPM
and the MTP. The MPM is a multimedia mail delivery system
following the specification of RFC 759. This is now working on
TOPS20, and was demonstrated at the end of the meeting. The MTP
is a text only mail server for multinetwork operation and follows
the specification of RFC 772. This is partially implemented on
TOPS20. It can now accept mail via TCP connections and leave it
for distribution via mailer and NCP connections. MTP was
demonstrated at the end of the meeting. Another program was
developed to better understand using TCP and can be used as a user
Telnet. This program is called TT. A description was distributed
at the meeting and TT was demonstrated at the end of the meeting.
Other work at ISI included the development and installation of
Postel [Page 6]
IEN 175
Internet Meeting Notes
code in the TOPS20s to guard against sending the 9th outstanding
message to the same destination in the ARPANET and thus be blocked
by the IMP. This has been installed in the five TOPS20s at ISI.
The PDP-11 which is the front end for the Penguin printer has been
modified to also route internet datagrams to other hosts on the
ARPANET or the local Ethernet. The WBC project has participated
with Lincoln in the Speech experiments reported on by Lincoln.
Also the WBC project has interfaced a radio clock to the speech
host so that the operating system (EPOS) gets the time from the
radio clock.
K. DoD
Ray McFarland mentioned that questions are being raised about the
Internet Addressing and its implications for Network
Architectures, and on the relationship between Internet
Architectures and Distributed Processing Systems. Later in the
meeting Ken Shotting discussed his work on specification of IP.
L. DCEC
Ed Cain gave the report on DCEC activities. The hosts in the EDN
now do reassembly. There are two gateway programs. The old
gateway does fragmentation, talks GGP, and sends in CMCC reports.
The new gateway performs well. There was some confusion about GGP
routing messages.
It seems that a type 11 message was used in the BBN-built gateways
to avoid confusing a new routing message format with the one
documented in IEN 109 (How to Build a Gateway). The DCEC gateway
used the type 11 message in order to exchange routing information
with its neighbors. However, since the agreed-upon resolution is
to modify IEN 109 to show the new format, the BBN-built gateways
have been gradually reverting back to the new-format type 1
message. During the transition, the DCEC gateway has kept track
of which gateways use the two routing types, and serves as a
routing "bridge" between the two communities. The right type code
for routing messages is Type 1, and no Type 11 messages should be
used anymore.
DCEC also implements the security and precedence features of IP.
A TIU for AUTODIN II is being developed by DCEC, and an
implementation of MTP is in progress. DCEC coordinated a seminar
on IP and TCP at NBS in November which 405 people attended.
Postel [Page 7]
IEN 175
Internet Meeting Notes
Action Items from DCEC:
1. How do we provide testing facilities to companies that
develop TCP products?
2. How do we control transit traffic?
M. COMSAT
Dave Mills gave a brief review of the configuration at COMSAT.
The most important new development is the idea of virtual hosts
which are processes with internet address and move from one real
host to another within the DCNET. Another idea being developed is
the maintenance of synchronized clocks in the hosts of the DCNET.
This is done with time stamps in routing update messages between
the hosts. Dave reported some interesting results about clocks
and time variations that came to light in this work (see IEN 173).
Also at COMSAT a MTP mail server is working. The FAX program now
handles multipage documents. NIFTP works between COMSAT and ISIE
-- 5 million bytes of RFCs and IENs were transferred. The
INTELPOST project conversion to IP/TCP continues. A copy of the
DCNET software has been installed at FORD research center at
Dearborn with a 1200 baud dial up connection between Dearborn and
Washington.
N. BBN
Jack Haverty reported on the development of three new TCPs: for
the TAC, the HP3000, and the VAX Unix. In the TAC, the TCP
connection opening and closing has been completed, and work
continues on the data handling code. In the HP3000 version the
TCP is done and work is in progress on Telnet while waiting for a
hardware interface. The VAX Unix (and C70) version is passing
packets but work on TCP continues. The work on the VAN gateway
(ARPANET/TELENET) continues; testing of X.25 level 3 is being done
with an Applied Data Communications Pro/Tester. The TIP Login
design is just about done; it is being designed as a special case
of resource allocation. BBN is modifying CMOS for use in the C50
environment. The CMCC data has shown some anomalous behavior.
For example short periods (5-10 minutes) with a high percentage of
dropped datagrams and at the same time NCC data showing very busy
IMP's. Hard to track this down -- better fault isolation tools
are needed.
Ginny Strazisar reported on the developments in the BBN-built
gateways. A new version of the gateway code was distributed to
all sites (except Ft. Bragg) which will do fragmentation (but not
with options). The gateway at UCL was modified to only use small
Postel [Page 8]
IEN 175
Internet Meeting Notes
(SATNET size) buffers and remove local operator support to improve
performance. The fragmentation routine will send on fragments as
large as the network can handle. Work is in progress to change to
a routing procedure which detects partitioned networks.
Dale McNeill reported on SATNET. After several months of poor
performance, on November 6 there was a significant decrease in
packets received with checksum errors on the SATNET channel.
Performance is consistent with a change in the BER from about
10**-4 to about 10**-6. No information on the potential cause has
been given by INTELSAT. In any case, SATNET channel protocol
stability and the ARPANET direct connection via SATNET performance
(ARPANET line 77 to the London TIP) are much improved. The
US-Norway ARPANET satellite circuit (ARPANET line 41 between the
SDAC IMP and the NORSAR TIP), which was changed last spring from
commercially-controlled to military-controlled, continues to
provide poor service. This line is composed of a military
satellite hop and a number of commercial circuits. Hence, NDRE
gateway to UCL gateway traffic is still disallowed in the Tanum
Satellite IMP, thereby breaking internetwork traffic between the
two gateway sites. A bug in the Host-SATNET protocol was found,
and a fix was installed in the Satellite IMPs. The same fix needs
to be inserted in the gateway to provide complete protection in
the protocol. A major milestone was passed in MATNET, the secure
shipboard copy of SATNET being built for the Department of the
Navy; namely, a Satellite IMP successfully transmitted packets
through a Navy FLTSAT satellite for the first time. The test
setup was at the plant facility of E-Systems, ECI Division, where
preliminary integration is being done between the network
controllers and the radio equipment.
Action Items from BBN:
1. Rubber EOL and Buffer Size has implementation impact in
TAC.
O. ARPA
Vint Cerf reported that the ARPANET switched over to 96-bit
headers on January 1st. Bill Carlson is leaving ARPA to join
Western Digital and plans to build ADA machines. Vint mentioned a
project at CCNY which is encoding video using adaptive delta
modulation. ARPA plans to make a pair of these devices available
to ISI and DCEC in July 1981. ARPA plans to replace all the 316
TIPS by TACs plus C30 IMPs. TIP Login will be used for access
control. Germany and Italy are likely to join SATNET soon, Canada
is in the discussion stage.
Postel [Page 9]
IEN 175
Internet Meeting Notes
P. CSNET
Dave Farber gave a brief overview of CSNET. The idea is to
provide network services to a group of university computer science
departments. It is a 5 year NSF grant. The contractors are
University of Wisconsin, University of Utah, Purdue University,
The RAND Corporation, and 9 others. There is a steering committee
(Chair Bill Kerns, NSF) and a technical committee (Chair Dave
Farber, UDEL). CSNET will use Telenet, ARPANET, and telephones to
connect the universities. The services to be provided are:
Computer Mail, File Transfer, Terminal Access, and Distributed
Processing Applications. More information is available from Dave
(FARBER@UDEL).
Q. DTI
Gary Grossman gave an overview of DTI's work on a front end for
the WWMCCS H6000 hosts. The INFE (interim network front end) has
been up for some time, and has had some testing. It implements
the January 80 IP and TCP and has been tested with the EDN
systems. DTI is now working on the COS/NFE which is to be
multi-level secure and will be based on DTI's HUB (TM) operating
system. The COS/NFE is to be verified by SDC.
R. NAVELEX
Frank Deckelman described the interests and activities of NAVELEX
Code 330. There are four areas: DBMS, Distributed Processing,
Decision Aids, and Networking. In Networking the focus is on:
Global networks (e.g., MATNET), local networks (e.g., CCN - uses
Ungerman-Bass hardware), and C2 work stations (multimedia and AI).
One current program that involves all four areas of responsibility
is the ACCAT at NOSC and the Remote Site Modules at NPS, FNOC,
CINCPACFLT, NRL, and other sites.
S. XEROX
John Shoch gave a brief status report on networking at XEROX.
There are between 30 and 40 networks in operation, connected with
20 to 30 gateways. The new 10 Mb Ethernet is up. The XEROX
series 8000 products are based on the Ethernet. There is a Print
Server, a File Server, and a Communication Server (gateway), as
well as work stations. John also mentioned that a paper on
"Measured Performance of the Ethernet Local Network" appears in
the December 1980 issue of the Communications of the ACM.
Postel [Page 10]
IEN 175
Internet Meeting Notes
IV. ACTION ITEMS
A. The problem reinitializing UCL gateway was resolved.
B. The design notes on the VAX, HP3000, and TAC TCPs were done [see
IENs 166,167,168].
C. The memo on IP Errors and GGP style messages was distributed in
DRAFT form.
D. The demonstration of the SRI Name Server was postponed
indefinitely.
E. The MTP was demonstrated at the meeting.
V . PROTOCOL SPECIFICATION AND VERIFICATION
A. Overview
Carl Sunshine gave a well-received presentation on formal models
for protocol analysis. Carl presented a basic model of a protocol
and identified the aspects that need to be specified and verified.
Then he described the methods for specifying protocols and
identified particular programs or techniques that implement each
method. Finally, Carl reviewed the verification methods and again
identified particular systems which implement each method.
The specification methods are:
Programs
inductive assertions
State Machines
FSA
Abstract Machines
Petri Nets
Sequence Expressions
The verification methods are:
Program verification
State Exploration
Structural Induction
Symbolic Execution
Design Rules
A DRAFT version of a report on "Formal Modeling of Communication
Protocols" was distributed. The final version is ISI RR-81-89.
Postel [Page 11]
IEN 175
Internet Meeting Notes
B. Three Way Handshake
Danny Schwabe presented an analysis of the three way handshake
made in the SPEX language. A description of a protocol in SPEX is
a "spexification." Spexifications can be translated into an
AFFIRM abstract data type. Proofs of properties of this abstract
data type can be done using AFFIRM. The analysis revealed a
possible problem in the three way handshake. As currently
described in the TCP specification (IEN 129), a connection may
become established on one side and potentially may accept data
from a previous incarnation of the connection. This is a very low
probability case and would be quickly detected, but the analysis
showed it was possible in principle.
The problem is that the document is in error in allowing an ACK to
be accepted before a SYN has been received.
A DRAFT report "Formal Specification and Verification of a
Connection Establishment Protocol was distributed.
C. IP Specification
Ken Shotting described his specification of IP using SRI's HDM and
SPECIAL. Ken broke down IP into several mini-layers to make use
of the methodology. There was some difficulty making assertions
about global behavior since several fields are changed between the
source and destination, e.g., Time-to-Live. This also causes
problems with the checksum field. The order of processing assumed
for various features has an impact on the formal specification.
Ken's evaluation of HDM for protocol analysis is that it provides
good support for developing a hierarchy of abstract functions and
for state machine transitions, but is weak in data representation,
exception handling, and concurrency. Ken's work is documented in
a University of Maryland Technical Report "On the Formal
Specification of Computer Communication Protocols," Computer
Science TR-973, December 1980.
D. NBS Work
Jack Haverty gave an overview of the work BBN is doing for the
NBS. The work is being done by Tom Blumer (TPB@BBN-Unix) and
Richard Tenney (RTenney@BBN-Unix). This protocol specification
system is based on a finite state machine model, augmented so that
there are variables, and arbitrary program segments may be
associated with each transition. These program segments are
written in a Pascal-like language. There is a syntax checker for
specifications, a specification editor, a FSM analyzer, a compiler
that produces C and a test generator.
Postel [Page 12]
IEN 175
Internet Meeting Notes
For further information contact Tom Blumer or see BBN Report 4581.
E. DCA Work
Dave Kaufman reported on the work SDC is doing for DCA. The main
emphasis is on developing complete specifications of existing
protocols based upon the original design intent and upon a set of
specification guidelines being prepared in parallel by SDC. These
guidelines include the following sections: Introduction, Service
Specification, Lower Level Service Specification, Interface
Specifications, Peer Level Mechanism Specification, and Execution
Environment. These sections correspond with the basic protocol
model presented by Sunshine. A distinction is made between the
service specification which is the global view of the service and
the interface specification which is the user/service local
interface. The execution environment section describes protocol
requirements of the operating system (or more correctly of the
protocols runtime environment) such as timers and interprocess
communication. IP is currently being specified according to these
guidelines and during this effort several areas have been
uncovered which require further definition.
Example areas noted by SDC were:
1. Who supplies the "protocol" field for the IP header, IP or
the transport protocol?
2. What is the nature of the interaction between IP and GGP?
3. Is source routing loose or strict?
Jack Haverty raised an additional related issue:
4. How does IP interact with the local net, on errors, on flow
control,etc.?
F. NDRE Work
Yngvar Lundh noted that a graphical technique had been used to
produce an augmented state machine description of TCP for use in
an NDRE implementation effort.
Postel [Page 13]
IEN 175
Internet Meeting Notes
VI. FRONT ENDS
A. Overview
Vint Cerf introduced the subject of Front Ends for protocols and
TCP in particular. The idea seems to be that in some cases IP/TCP
etc. may be too complex to put into the existing operating system,
so the protocol modules are put into a small front end machine.
Then there must be a communication procedure between the host and
the front end. This communication procedure is called Host-Front
End protocol (HFP). The argument is that HFP is much simpler for
the host than IP/TCP would be. Note that not everyone shares this
view.
B. WWMCCS HFP
Gary Grossman gave a detailed presentation on the HFP developed
for the WWMCCS H6000 machines. DTI has developed a protocol for
use between the host and the front end based on the notions of
"services" and "channels." The lowest level of the HFP is the
link level which provides a single channel with flow and error
control. The function of the link level corresponds to the
functions of an HDLC connection. The middle level is the channel
level. This is the level where separate logical streams appear
and are multiplexed based on logical channel number. At the top
level are services (i.e. applications). Typical services would be
Telnet and FTP. Gary gave quite a bit of detail on the protocol
formats and control procedures.
Gary also talked about the specification technique used to
describe the HFP. For each message type the following points are
described: function, when sent, sending state (and next state),
receiving state (and action to take), subsequent actions by sender
and receiver. For the service protocols, a specification includes
a "specification" and an "adaptation." The specification gives
the semantics of the fields used and the procedure for
communicating via the channels. The adaptation gives the format
details and any restrictions due to the particular machine
environment.
DTI and MITRE have done a fair amount of performance testing. The
comparison of an old implementation of NCP in the H6000 versus an
NCP implementation in the Front End show the Front End about 2 to
1 better in throughput. There are many differences in the two
configurations. Some testing recently showed that from the H6000
through the FE and over the ARPANET to DTI a data rate of 18Kb/s
was achieved. In local tests, 64Kb/s was measured over the
H6000-->FE-->I path; and with a source and sink in the FE, 84Kb/s
Postel [Page 14]
IEN 175
Internet Meeting Notes
was measured for source-->I-->sink. Finally using a "mirror"
program in the FE instead of sending to the IMP, 125Kb/s was
measured for source-->mirror-->sink. An analysis of the CPU time
in the TCP code in the FE revealed that about 20% of the time was
spent on TCP functions and 80% on interprocess communication and
other "system" functions in the monitor.
Gary noted that details of the HFP are described in DTI report
DTI-80043.C-INFE.18, and DTI-78012.C-INFE.14, and the measurements
are described in the papers "Control Structure Overhead in TCP,"
NBS Computer Networking Symposium, May 1980, and "A Performance
Study of a Network Front End," Sixth Data Communication Symposium,
November 1979.
C. Z8000
Steve Holmgren of MITRE described a Z8000 based TCP. The goal is
to provide network communication for very small hosts which might
otherwise be peripheral devices of a computer. The Z8000 actually
supports a Network Access Protocol (NAP). The NAP is a layered
protocol with an option approach. The layers are: link,
transport, service, and user. The option approach allows the
users of the protocol to select the features they need and to
ignore others.
Steve gave some details of the protocol functions and formats.
The access to the protocol is via a system call style mechanism,
and the user is allowed to pass parameters and select options.
D. Discussion
John Shoch said he questioned the desirability of Front Ends, and
wondered, if aside from communication efficiency and pragmatics,
there was a good technical principle for front ends?
It was noted that we often excuse the current work of computing
checksums by saying we will someday have a checksum instruction in
our machines. Steve Holmgren asked "Why not a TCP instruction?"
When does a "front end" become an "instruction?"
Postel [Page 15]
IEN 175
Internet Meeting Notes
VII. PERFORMANCE
A. Multics
Dave Clark discussed his measurements of TCP performance in
Multics. Dave described some detailed timing studies made of the
different TCP functions. The IP implementation is 5.3 K
instructions, and the TCP implementation is 9.0 K instructions.
Dave also discussed throughput in TCP when there is a lot of data
to send (e.g., in file transfers). A problem, previously pointed
out by Dave Mills, can arise where many small segments are sent.
This is due to the receiver reporting additional window each time
a small amount of the data has been processed, and the sender
immediately sending a segment to fit that additional window. Dave
Clark proposes to call this phenomena "Silly Window Syndrome"
(SWS). One way to prevent SWS is for the receiver not to report
new window unless the increase is a reasonable size. The receiver
can acknowledge incoming segments at any time, but limit window
updates to points when a reasonable increase can be made. It is
up to the receiver to decide what is reasonable, perhaps something
like 20% of the total buffer space for this connection. The
sender can also try to stay out of SWS by only sending big
segments and waiting until the window is large enough to allow it.
If the sending user indicates an end of letter then a smaller
segment may be sent.
Dave suggests that sending a segment with one octet of new data
into a zero window as a probe may lead to SWS. It may be better
to send an octet of old data.
Dave suggested that a performance measure might be the size of
bursts of segments the net, gateway, or host could handle. For
example, can a gateway handle a burst of 10 datagrams of 576
octets at the network input speed? Could measures be devised and
feedback control be exercised in terms of bursts? Wild idea
number one: the receiver can tell the sender the maximum burst
size it should send. Wild idea number two: have gateways turn on
a bit in the IP header if they are busy, and have the receiving
hosts integrate this information for use in determining a burst
size to feedback to the source.
B. UCL
Ron Jones reported on measurements of datagram traffic between UCL
and ISIE. The source of the traffic was an LSI-11 host. This was
connected to a port expander. The PE was in turn connected to the
UCL Gateway. The UCL Gateway communicates via the Goonhilly SIMP,
Postel [Page 16]
IEN 175
Internet Meeting Notes
the SATNET, and the ETAM SIMP, to the BBN Gateway. The BBN
Gateway sends the datagrams through the ARPANET to ISIE.
Ron had a number of measurements which he described, but interest
focused on the discovery that in some tests from 25% to 90% of the
datagrams were lost between the ETAM SIMP and the BBN Gateway.
Some of the tests showed a significant step in the throughput
graph at the single-packet/multi-packet threshold.
C. BBN
BBN believes that the problem originated because the ARPANET
IMP 40 would not accept packets from the BBN gateway fast enough.
The packet loss is manifest as multiple packet retransmissions
from the Etam SIMP to the BBN gateway, until the packet eventually
times out and is discarded in the SIMP. This behavior underscores
two inadequacies in the system. First, the BBN gateway should
discard the packet and send the appropriate message to the Etam
SIMP; the machinery is already present in Host-SATNET protocol to
accommodate this. Second, the Etam SIMP should notify the
Goonhilly SIMP which should notify the UCL gateway that problems
are arising. Unfortunately, a flow control mechanism like source
quenching was never developed within SATNET, although its need has
been known for some time; hence, when packets are dropped in
SATNET, gateways are never informed and therefore cannot generate
internet source quenching messages.
D. RSRE
John Laws presented some findings of measurements performed by
Andrew Bates. These are datagram measurements of a single round
trip (at earlier meetings RSRE has reported on TCP measurements of
double round trip times). The source/sink is a TIU connected to
the RSRE gateway. One set of measurements seems to show that the
round trip time to the ETAM SIMP is about 2 seconds with very
little spread, but the round trip time to the BBN Gateway is also
about 2 seconds but with about 25% of the datagrams delayed (a
bimodal Histogram). The measurements were made at different times
of day, and may be due to a difference in the load on SATNET.
E. CMCC
David Flood Page told of tracking down the cause of some looping
datagrams. In December the CMCC data showed that in the course of
a day one of the PRNET/ARPANET gateways had processed several
million datagrams. When the people who normally use that gateway
were asked what experiment they were conducting, they replied
"What experiment? We aren't doing anything." Several instances
Postel [Page 17]
IEN 175
Internet Meeting Notes
of this incredibly high traffic level in at least two different
PRNET/ARPANET gateways were detected over the next several weeks.
David began investigating and eventually found the cause.
The loader server that loads the port expanders attached to the
PRNET gateways uses XNET 2.5, with Internet 2.5 headers, to do the
loading. The loader server sends the packets to logical host 15
(decimal) on the port expanders ARPANET address, which is the
address recognized by the bootstrap (obviously). The last packet
sent by the loader server is the one that says "go" to the
bootstrap; this causes the bootstrap to send out an acknowledgment
and then start up the port expander software. One of the first
things the PE does is to flip the ready line to the IMP. Now if
the acknowledgment from the bootstrap is still in the IMP, and the
IMP sees the ready line down, it will drop the ack (and any other
outstanding packets from that host). So the loader server gets no
ack, and retransmits the "go" command.
The "go" command arrives at the port expander addressed as before,
i.e. to logical host 15 on the PE; but the PE doesn't have a
logical host 15. It is set to hand off any packets which it
doesn't know how to route to its logical host 0, which is the
gateway; the gateway sees that it is a packet destined for
somewhere on the ARPANET that is not itself, so sends it back out
its ARPANET interface, i.e. to the PE. The PE has the same
trouble as before, so we get a loop. Because the packet is an
Internet 2.5 packet, it does not have a time to live field, so the
packet loops indefinitely until either the PE goes down, the
gateway goes down, or a flood of real packets causes enough
congestion to result in the dropping of the looping packet.
This didn't happen every time the PE was loaded, because some of
the time, the acknowledgment got out of the IMP fast enough not to
be dropped when the ready line was flipped. It was largely a
matter of luck.
The problem will disappear either when the new gateway version,
which drops all Internet 2.5 packets, goes into the PRNet
gateways; or when the V4 bootstrap goes into the PEs. In fact I
think the new gateway version may already be in place. Holly did
put a fix in the PE as well, but I'm not sure what it was. One
important point to note is that the port expander is on the
ARPANET side of the gateway, not the PRNet side.
David says the lesson that should be learned from this is that
more remote access to debugging tools is needed. The key piece of
evidence in solving this problem was provided by a "packet
Postel [Page 18]
IEN 175
Internet Meeting Notes
printer" trace program that could only be run locally at the
gateway/port expander site - which is normally unmanned.
F. Radio Clocks
Steve Casner described (actually showed) one of the Radio Clocks.
Since we are about to start doing coordinated measurements of one
way times we must have an agreement on what size and precision of
time stamps to carry around in datagrams and programs. The "no
thought" proposal is 32 bits of milliseconds since 1 January 1980.
Others suggested that we might want more precision later so maybe
we should have micro seconds and more bits. This was not
resolved.
VIII. WORM PROGRAMS
John Shoch briefly described an experiment in distributed computing.
Programs were constructed to operate in segments with each segment
allocated to a personal computer. The total program is called a
worm. The basic version of the program simply maintains its
existence. If a segment dies the remaining segments cooperate to
find a free machine, load it with the segment code, and start it
running as part of the worm. John described some of the interesting
things which can go wrong, and ways to prevent them. The experiment
is discussed in more detail in IEN 159. One comment to the internet
group is that this experiment showed the usefulness of
multidestination or group addresses. The conclusion is that with
datagram style communication, high speed local networks, and new
control procedures, the tools are in hand to begin some very
interesting multi-machine applications.
IX. IP ERRORS
Jon Postel distributed a draft memo on error reports in IP. The memo
is titled "What every host should know about GGP". The intention is
to use the GGP messages on routing advice and destination dead as a
base and to add a few other messages to cover the host-to-host error
conditions. The discussion focused on whether or not this should
remain part of GGP or be in a separate protocol. From an
implementation point of view there seems to be little difference,
from an administrative point of view it seems to be cleaner for it to
be separate. There were some strong difference of opinions. The
matter was not resolved.
Postel [Page 19]
IEN 175
Internet Meeting Notes
X. ADDRESSING DISCUSSION
A. Overview
Vint Cerf opened the topic with a call for a very general
discussion of the issues and spent some time developing a list of
goals for the the addressing and routing procedures. The goals
were:
1. Keep routing simple.
2. Keep routing tables small.
3. Keep computation costs small.
4. Most datagrams should be delivered.
5. Use any available connectivity.
6. Multidestination delivery.
7. Handle mobile hosts.
8. Efficiently use constituent networks.
9. Support multi-homing.
10. Dumb hosts should be included.
11. Pantheism should be dealt with.
12. Degradation should be automatically fixable.
13. The system should scale up.
14. The system should be measurable.
15. Ability to use hierarchy.
There was some discussion of these points and it was noted that
some are service specifications while others are "good job"
criteria.
B. Presentation
Noel Chiappa described the MIT complex which includes 9 networks
and three major protocol families (IP, PUP, and CHAOS). All these
networks share one "Internetworkly known" network number. Noel
Postel [Page 20]
IEN 175
Internet Meeting Notes
listed a number of problems and made some observations. One
possible long term development may be that all hosts are on local
networks and only gateways are attached to long haul networks.
The thrust of Noel's remarks seems to be that things are going to
grow in a complex, but generally hierarchical, way; and any
workable system will have to be prepared to grow, probably by
taking advantage of the structure.
C. Discussion
Vint Cerf led a further discussion on addressing. The main focus
was on the tradeoff between a flat address space and a
hierarchical one. In a flat address system there is no relation
between the address and the location, and routing has to be by
central knowledge or broadcast. In a hierarchical address system
the address is composed of fields which identify the location in a
routing tree.
Vint suggests that we have both in one! Let an address be
composed of two parts: a hierarchical address (called an address)
and a flat address (called an identifier). The address can be
used as a routing guide or hint, but the identifier must match for
a message to be delivered. The identifiers are globally unique
names for hosts and do not change when hosts move.
There are many questions to be answered in this scheme. For
example, How does source routing work? Or Multi-homing?
XI. FILE TRANSFER IMPLEMENTATION STATUS
Vint Cerf took a survey of the implementers present to find out the
status of FTP implementations. There are four different FTP systems
being used: ARPA FTP (RFC 765), AUTODIN II FTP (IEN 101), NIFTP (IEN
99), and TFTP (IEN 133). The first three use TCP, and the last
(TFTP) uses UDP.
ARPA FTP
DCN (COMSAT) now
TOPS20 (BBN) April 81
EDN-Unix (DCEC) June 81
Multics (MIT) after June 81
AUTODIN II FTP
BBN-Unix (BBN) now
EDN-Unix (BBN) now
Postel [Page 21]
IEN 175
Internet Meeting Notes
NIFTP
TOPS20 (UCL) now
DCN (COMSAT) now
Multics (MIT) June 81
UCL-Unix (UCL) now
TFTP
Multics (MIT) now
TOPS20 (MIT) now
ALTO (MIT) now
Unix (MIT) now
TOPS20 (ISI) March 81
EPOS (ISI) April 81
XII. COMPUTER MAIL
A. Mail Facilities
Peter Kirstein discussed the problems of providing mail services
between users in the UK and the US. Within the UK, computer mail
will almost certainly be based on NIFTP and will likely be as
proposed in IEN 169. One major concern for the US/UK
transmission is cost. It is quite important that a minimum number
of transmissions be made and especially that only one copy of a
message destined for multiple users be sent across the Atlantic.
Peter raised the issue of an interface between NIFTP mail and MTP
mail, since it seems that the Internet will use the MTP mail.
B. Mail Transfer Protocol
Jon Postel discussed the MTP mail plan and indicated that a
revised document would be issued soon which will describe the MTP
in a network independent style.
Jon agreed with Peter that a NIFTP-mail/MTP interface data
structure should be defined soon, and promised to do so.
There are several working (or partly working) MTPs already:
Multics, COMSAT, DCEC, and ISI.
C. TELEX/TWX Gateway
Geoff Goodfellow described a system that is under development at
SRI to connect Telex and Computer mail. A user at a computer
terminal runs a program like SNDMSG or MM and simply adds some
Postel [Page 22]
IEN 175
Internet Meeting Notes
additional fields to the header of the message to give the
information needed for sending a telex. The message is routed to
a special host which checks the telex information and if it is
acceptable sends a telex. When a telex arrives at SRI it is
processed by the special host and if the required keywords and
information are found it is sent as a RFC 733 style message to the
recipients computer mail mail box. A small percentage of the
incoming telexes must be handled by a human operator because they
do not contain the required information in a computer parsable
form.
D. Discussion
There was some discussion of mailbox addresses and the problem of
sending (and answering) mail to (from) mailboxes in other systems
(e.g., Internet, TELEMAIL, ONTYME).
XIII. NEXT MEETING
The next meeting will be held 1-2-3 June 1981 at COMSAT in Washington
D.C. Dave Mills (Mills@ISIE) is the host. Please send agenda items
to Jon Postel (Postel@ISIF). If you plan to attend please register
with Linda (Linda@ISIF). Local arrangements information will be sent
only to those registering.
The fall meeting will be held at UCL on 21-22-23 September 1981. The
winter meeting will be held at SRI in mid January 1982.
Postel [Page 23]
IEN 175
Internet Meeting Notes
DOCUMENTS DISTRIBUTED
Author Subject Number
------ ------- ------
Cerf INFOCOM82 Call for Papers ---
Postel AGENDA ---
Postel Recent Document List ---
Postel IEN INDEX ---
Postel Assigned Numbers 776
Farber CSNET Description ---
Postel TT ---
Chase TTLUSR ---
Postel What Every Host Should Know About GGP ---
Cohen On IP-Addressing 170
Cohen Addressing in the ARPANET, another visit 171
Sunshine Formal Modeling of Communication ---
Protocols (DRAFT)
Schwabe Formal Specification and Verification of ---
a Connection Establishment Protocol (DRAFT)
Bennett A Simple NIFTP-Based Mail System 169
Postel [Page 24]
IEN 175
Internet Meeting Notes
RECENT DOCUMENTS
Author Subject Number
------ ------- ------
IENs
Shoch Notes on the "Worm" Programs - Some Early 159
Experience with a Distributed Computation
Postel Internet Meeting Notes - 7-8-9 October 1980 160
Jones A Proposal for Simple Measurement Support 161
for Users Through Slow Nets
Pershing Transport, Addressing, and Routing in the 162
Wideband Net
Jones Echo Delay Measurements with GGP Packets 163
Stern CMOS System Overview 164
Cohen About Addressing in the WBnet 165
Hinden Design of TCP/IP for the TAC 166
Sax HP3000 TCP Design Document 167
Gurwitz VAX-UNIX Networking Support Project 168
Implementation Description
Bennett A Simple NIFTP-Based Mail System 169
Cohen On IP-Addressing 170
Cohen Addressing in the ARPAnet, Another Visit 171
Mills Time Synchronization in DCNET Hosts 173
RFCs
Postel Internet Protocol Handbook 774
Table of Contents
Mankins Directory Oriented FTP Commands 775
Postel Assigned Numbers 776
Postel [Page 25]
IEN 175
Internet Meeting Notes
ATTENDEES
Name Affiliation Nationality Mailbox
---- ----------- ----------- -------
Vint Cerf ARPA USA Cerf@ISIA
Robert Kahn ARPA USA Kahn@ISIA
David Flood Page BBN British DFloodPage@BBNE
Jack Haverty BBN USA JHaverty@BBND
Robert Hinden BBN USA Hinden@BBNE
Charles Lynn BBN USA CLYNN@BBNA
Dale McNeill BBN USA DMcNeill@BBNE
Paul Santos BBN USA Santos@BBNE
Virginia Strazisar BBN USA Strazisar@BBNA
Gerry Amey Canada-DND Canadian Amey@ISIA
Hoi Chong COMSAT Rep. China Chong@ISIE
David Mills COMSAT USA Mills@ISIE
Marvin Solomon CSNET USA UWVAX!Solomon@BERKELEY
Ed Cain DCEC USA Cain@EDN-UNIX
Wayne Shiveley DCEC USA Shiveley@BBNB
Hans Dodel DFVLR Germany ---
Helmuth Lang DFVLR Germany ---
Gary Grossman DTI USA grg@DTI
Horst Clausen IABG Austria Clausen.IABG@Mit-Multics
Ray McFarland DoD USA McFarland@ISIA
Ken Shotting DoD USA Shotting@SRI-kl
W. Bradbury I.P. Sharp Canadian ---
Stephen Casner ISI USA Casner@ISIB
Danny Cohen ISI USA Cohen@ISIB
Randy Cole ISI USA Cole@ISIB
Dan Lynch ISI USA Lynch@ISIB
Bill Overman ISI USA Overman@ISIF
Jon Postel ISI USA Postel@ISIF
Danny Schwabe ISI Brazil Schwabe@ISIF
Carl Sunshine ISI USA Sunshine@ISIF
Estil Hoversten Linkabit USA Hoversten@ISIA
Jim Forgie LL USA Forgie@BBNC
Noel Chiappa MIT British JNC@XX
Dave Clark MIT USA Clark@MIT-Multics
Steve Holmgren MITRE USA Steve@MITRE
Anita Skelton MITRE USA Anita@MITRE
Frank Deckelman NAVELEX USA Deckelman@ISIA
Oyvind Hvinden NDRE Norway Oyvind@DARCOM-KA
Yngvar Lundh NDRE Norway Yngvar@DARCOM-KA
Merle Neer NOSC USA Neer@ISIA
Mike Wahrman RAND USA Mike@RAND-UNIX
Derek Barnes RSRE British T45(ATTN.Barnes)@ISIE
John Laws RSRE British T45@ISIE
Dave Kaufman SDC USA Kaufman@ISIE
Postel [Page 26]
IEN 175
Internet Meeting Notes
Geoff Goodfellow SRI USA Geoff@SRI-ka
Ron Kunzelman SRI USA Kunzelman@SRI-KL
Jim Mathis SRI USA Mathis@SRI-KL
Holly Nelson SRI USA HNelson@SRI-KL
Zaw Sing Su SRI Canada ZSu@SRI-KL
Ken Biba SYTEK USA Biba@SRI-KL
Ron Jones UCL British UKSAT@ISIE
Peter Kirstein UCL British PKirstein@ISIA
Charles Kline UCLA USA CSK@UCLA-Security
Dave Farber UD/CSNET USA Farber@UDEL
John Shoch Xerox USA Shoch@PARC
Postel [Page 27]