J. Postel
IEN 121 ISI
25 October 1979
Internet Meeting Notes - 10, 11, 12 & 13 September 1979
I. INTRODUCTION TO UCL - Jones
Ron welcomed us to UCL and discussed the arrangements for facilities,
refreshments, and lunch.
II. OVERVIEW AND OBJECTIVES - Cerf
Vint reviewed the need for a working internet system and cited the
performance of the system as a key issue. The development of
procedures to measure and test the performance of the internet are
now important. Vint has pointed out that several conceptual design
issues need to be resolved, for example, protocol support for voice
conferencing in the internet.
III. STATUS REPORTS
A. DARPA - Cerf
Vint reported that the Director of the ARPA Information Processing
Techniques Office, Col. Dave Russell retired on 31 August. The
new Director is Dr. Robert Kahn.
The standardization of IP and TCP for use as the DOD networks
protocol is progressing. Dr. Robert Lyons at DCEC is the
Executive Agent. The only changes that are necessary are to
incorporate mechanisms to pass the security and precedence
information between the application program and TCP, and between
TCP and IP. There already is an IP option to carry that
information in the internet.
There is a need for a way to test TCP implementations and
applications that use TCP without taking a service machine down.
For TOPS20s this will be satisfied by using BBNF. BBNF is
currently only on the BBN RCCNET but will be connected to the
ARPANET for October through December 1979.
Vint acknowledged that there have been hardware delivery delays
that have had a substantial impact on the internet program. The
delivery schedules from manufactures are very long.
Postel [Page 1]
IEN 121
Internet Meeting Notes
The program managers in the ARPA office are coordinating to have
all new applications use internet protocols.
B. BBN - Haverty, Plummer, Strazisar, McNeill, Flood Page
Jack reported that the BBN-Unix TCP is in regular use. Currently
work is in progress to provide a user interface to the IP layer.
The IP support is available as a subroutine package. The
interface will be similar to the TOPS20 interface documented in
IEN 108. BBN is also working on a VAX UNIX with the goal of
having the current 11/70 UNIX and VAX UNIX be compatible at the
applications level.
Bill reported on the plan to attach BBNF to the ARPANET for ease
in testing TCP and TCP using applications. In doing this testing
it is preferred to have one person at a time to simplify the
identification of problems. Note that one will have to use new
1822 (96-bit leaders) to access BBNF since it will be on IMP 67.
The latest IP and TCP and Telnet are installed at ISID and ISIE
TOPS20 Systems. In the last month or two several bugs have been
identified and fixed. The next major step is to complete the
TENEX version of TCP-4 and to eliminate any remaining instances of
TCP-2.5. It is assumed that both the Packet Radio Project and UCL
have completed their conversion to version 4, and that as soon as
the SATNET project completes its conversion version 2.5 can be
eliminated. The LDRSRV program was converted to use IP in a few
hours. An FTP on TCP, based on ARPA FTP, is in debugging.
Ginny reported that several gateways are running, most are MOS
based. It is planned to phase out the remaining ELF based
gateways.
MOS Gateways
at UCL between UCLNET and SATNET
at NDRE between ARPANET and SATNET
at BBN between ARPANET and SATNET
at SRI between PRNET and ARPANET
ELF Gateways
at Ft. Bragg between PRNET and ARPANET
It is planned to install a gateway at COMSAT between SATNET and
the COMSAT local net. There is a new monitoring system. A
configuration with a port expander and a gateway in the same
machine is planned, it will be a tight fit.
Dale reported on the SATNET conversion to use IP. There are still
Postel [Page 2]
IEN 121
Internet Meeting Notes
a number of programs to be converted, but it could be completed in
about a month. Most of the remaining programs are used for
maintenance or error recover. A weekend test was conducted using
IP only. The major event impacting SATNET will be the removal of
the NORWAY-LONDON ARPANET line at the end of September. This
means all the LONDON ARPANET traffic will be routed via SATNET.
David noted that the scheduled GMCC demonstration will be a
presentation, since there is nothing to demonstrate.
C. COMSAT - Mills
Dave reported that the ETAM and GOONHILLY PSPs are in the field
and the TANUM PSP will be shipped soon. There have been some
minor problems, for example, the software checksum and the
hardware checksum do not agree. It is expected that the PSPs will
be on the air next month.
Much of the COMSAT activity during the last few months has been
directed to the NTC Demo in November and development of the Demo
Terminal software. Currently, we have made arrangements for a
suitable room and are now planning installation of lines,
terminals and other gear. The demo will include speech, fax and
the usual interactive and bulk transfers between ARPANET hosts and
the Demo Terminal.
The Demo Terminal software has been checked out at UCL using an
LSI-11, floppy disk, LPCM and Port Expander connected to UCLNET
(net 13). TCP/Telnet was tested with ISIE via UCLNET, SATNET and
ARPANET. FTP was checked out in loopback mode via the UCL Gateway.
The LPCM was operated in expensive dictaphone mode only, since
support is not yet complete for SATNET streams. This software will
play with the Demo Terminal software at COMSAT and at the NTC
Demo.
At COMSAT a Dacom 450 FAX machine has been delivered. This will be
connected to the Demo Terminal and taken to the NTC site. Software
to support this machine is now in frenzied development. When
complete an update will be distributed to UCL. For local testing
we are trying to arrange a direct connection to ARPANET (avoiding
the SATNET for the time being) for debugging.
D. DCA - Cain
Ed reported that DCEC has a small (2-page) "C" program running in
an 11/34 with two 1822 interfaces which implements a gateway.
Postel [Page 3]
IEN 121
Internet Meeting Notes
E. DOD - McFarland
Ray noted that mid October is the target date for the draft DOD
Standards IP/TCP document. These documents will be rewritten to
military document conventions.
F. ISI STATUS - Postel
Jon noted that ISI is not implementing any IP, TCP or Gateways.
ISI did attempt to write a program that used TCP on TOPS20. This
program did not work (TOPs'20 crashed). Debugging is in progress
with Bill Plummer and the ISI systems staff. ISI is working on an
Internet Message Program. This is in an early testing phase and
will be using TCP for inter module communication.
G. LL - Forgie
Jim noted that the main Lincoln effort has been on the ST protocol
to be discussed later and described in IEN 119.
Experiments with ARPANET-SATNET speech have been conducted with
one source/destination in the ARPANET and another in the SATNET.
There have been unexpectedly large delays in the SATNET streams,
and in matching the ARPANET to the SATNET in the special purpose
Gateway.
H. MIT - Clark, Chiappa
Dave discussed the status of the LSCNET. There is a 5 node system
up and running. The development of a version 2 interface is in
progress. There has been difficulty getting an LSCNET/ARPANET
gateway working due to low level hardware problems. A Trivial
File Transfer has been implemented directly on IP. In Multics the
IP layer will act as a gateway. MIT will be involved in the
XEROX Grant program. Dave will be involved in integrating the
Xerox equipment into the LCS environment. A PDP-11 based gateway
between LCSNET and the ETHERNET is contemplated.
Noel commented that he saw a need for an effort to be made to
convince groups to use IP rather than invent their own protocols.
I. NDRE - Stensby
NDRE has been assisting in the preparations for the speech demo.
The protocol status is nearly the same as last reported. This is
due to VDH connection problems. Much work has been done on
debugging the connection. Possible bugs have been very difficult
to track down because we lack control of vital parts of the
system. A couple of bugs have been found and corrected in the
Postel [Page 4]
IEN 121
Internet Meeting Notes
NORD-10 VDH software without any substantial effect. The real
problem seems to be that at certain times when the TIP has sent a
packet out of sequence, it keeps retransmitting this packet
instead of retransmitting the packet that is really missing.
J. RSRE - Davies
Brian reported that RSRE has programmed a gateway (based on
IEN 30) and attempted to bring it up as a catenet gateway between
UCLNET and RSRENET. RSRE will be bringing up a host with IP and
TCP in about a month.
K. SRI - Kunzelman, Mathis
Ron reported that SRI is now operating two PRNETs in the San
Francisco bay area, and one PRNET at Ft. Bragg, North Carolina.
The net at Ft. Bragg is now eight terminals on two TIUs, and will
grow to forty terminals.
Jim reported that the LDRSRV at SRI-KA which now uses TCP-2.5 will
be changed to use version 4 soon, tested at BBNF, and installed at
ISID and ISIE. Jim is also working on a Port Expander and Mini
Gateway combined.
L. UCL - Kirstein, Jones, Treadwell, Cole, Bennett, Higginson
Peter gave a brief overview of the UCL effort, then let various
members of the UCL group give reports on their activities.
Ron discussed the problems of including network software in a
small Unix system. There was also some discussion of port
expanders and X.25/IP interfaces.
Steve reported on the situation with the FAX experiment. The main
problems seem to be with the timing constraints of the device, and
matching these to the flow control constraints of TCP. This
system currently uses TCP-2.5 but will convert to version 4 soon.
Bob reported on the development of a "C" to MOS linkage.
Chris discussed the prototype NIFTP service that allows FTPs from
EPSS to Tenex and vice versa. A Unix version of NIFTP has been
implemented.
Peter discussed the many flavors of X.25 one finds when building
X.25/XXX interfaces.
Postel [Page 5]
IEN 121
Internet Meeting Notes
M. IRIA & CELAR - Zimmerman
Hubert said that IRIA and CELAR would like to explore the
possibility of cooperative research on the interconnection of
networks. IRIA is working on local networks and interconnection
with TRANSPAC and CYCLADES.
N. UNIVERSITY OF ROCHESTER - Lantz
Keith gave a brief overview of the environment at the University
of Rochester and indicated the interest in becoming part of the
internet system.
IV. ACTION ITEMS
A. DOCUMENTATION STATUS - Postel
Jon reviewed the IENs issued since the last meeting.
IEN Author Title
--- ------ -----
108 Plummer Internet User Queues
Describes the TOPS20 user interface to the IP.
109 Strazisar How to Build a Gateway
Describes the messages Gateways exchange with each other and
with hosts, i.e., the Gateway-Gateway protocol. The main
focus is on the computation of connectivity and routing
information. Replaces IEN 30.
110 Cerf Internet Addressing and Naming in a
Tactical Environment
Presents several addressing problems, particularly the
"flying packet radio" problem.
111 Postel Internet Protocol
112 Postel Transmission Control Protocol
The latest editions of the IP and TCP specifications. Not
intended to be a change to the protocols but a better
documentation of them. Replaces IENs 80 and 81.
Postel [Page 6]
IEN 121
Internet Meeting Notes
114 Postel Protocol Options
Summarizes the option available with IP and TCP. Replaces
IEN 92.
115 Postel Address Mappings
Shows how the addresses of various networks are carried in
the Internet Address format. Replaces IEN 91.
116 Postel Internet Name Server
Specifies the Internet Name Server, including same new
features suggested by John Pickens. Replaces IEN 89.
117 Postel Assigned Numbers
Lists the assigned number for various protocol fields, e.g.
Networks, Sockets or Ports. Replaces IEN 93.
118 Postel Internet Protocol Handbook
Table of Contents
A one page list of the IENs that specify the current
internet protocols. Replaces IEN 94.
119 Forgie ST - A Proposed Internet
Stream Protocol
The description of a Internet level protocol for voice
conferencing. Includes features for establishing
multi-addressee connections.
The discussion that followed suggested several things that should
be documented. For example, the higher level protocols (Telnet,
FTP) should be in the internet protocol handbook, the procedure
for determining parameters (e.g. retransmission timeout) should be
documented, what to do in exception conditions should be
described, testing procedures should be discussed (especially an
acceptance test).
Concern was expressed that the new editions of the IP and TCP
specification were not suitably reviewed by the implementors. It
was suggested that a version with changes marked would be useful
(see Appendix B).
Postel [Page 7]
IEN 121
Internet Meeting Notes
B. EXPECTED DOCUMENTS
1. IP Generic Services - Do the two documents 1) the IP Spec by
Jon (IEN 111), and 2) the Gateway Spec by Ginny (IEN 109),
supply the information needed?
2. SATNET IP Services - Dale McNeill is working with Dave Mills
(currently the only user). When the current experiments are
completed a document will be produced.
3. Transition Plan - Vint will discuss the issues in a small
group meeting and appoint a task force to prepare the plan.
4. Host IP Services - Bill Plummer will prepare a document based
on his talk on How to Build a Host IP.
C. XNET - It seems that XNET is not yet fixed to work with IP due to
a technical disagreement between Jim Mathis and Ray Tomlinson.
The solution to this is to be reported on at the next meeting.
D. Hack IP at SRI-KA and LDRSRV - This is working according to Jim
Mathis.
V. INTERNET TRAFFIC EXPERIENCE - Davies
RSRE has conducted some experiments sending messages looped back to
themselves, with the loopback being located at various places, and
using several input speeds and block sizes.
At RSRE there is a multi-terminal TIU with some modifications to
perform measurements. The TIU measures the time between the TCP
segment first being sent and the acknowledgment arriving, a kind of
round-trip time.
The path is TIU via 2.4Kb line to PIXIE to PORT Expander to TIP into
ARPANET. The input was either typing, a 1 octet segment traffic
generator, or a 128 octet segment traffic generator. Histograms of
performance under various inputs and loopback points were presented.
The results indicate lower than expected performance and the
speculation was that the limiting factor was the program interrupt
1822 interface (either in PIXIE or the Port Expander).
It was noted that when two traffic generators were run sending
segments to each other, ACKs were piggybacked 100% of the time both
at the TCP level and at the X.25 level (recall the RSRE to PIXIE line
operates the X.25 level 2 link protocol).
Postel [Page 8]
IEN 121
Internet Meeting Notes
VI. HOW TO BUILD A GATEWAY - Strazisar
Ginny discussed the way gateways determine how to do routing. The
actual messages used are documented in IEN 109.
A gateway gathers information on network connectivity by polling its
network interfaces and known neighbor gateways. The polling is done
by sending a message, currently every 30 seconds. There is an
algorithm to decide if a net or gateway is up or down based on the
results of the polling. The routing algorithm is based on a distance
measure, a directly connected network is zero distance, an
unreachable network is infinite distance. The gateways exchange with
neighbors their distance tables (substituting infinity in entries
where the distance to the destination is greater than the distance
from the neighbor). Routing information is sent only when something
changes. A new gateway can join the system as long as old gateways
can add a row to their tables dynamically.
Note that "smart gateways" do all this routing and connectivity work,
"dumb gateways" do not. Smart gateways try to route things to other
smart gateways, but if that can't be done they may fall back to using
compiled in fixed routes to dumb gateways.
Danny Cohen suggested that there may be problems with this algorithm
as the number of networks gets large.
VII. HOW TO BUILD A HOST IP - Plummer
Bill presented the general flow of processing in a Host IP. In
general datagrams arrive from the connected network interfaces. Any
fragmented datagrams are reassembled. Complete datagrams are entered
into a queue. Datagrams addressed to other hosts may be forwarded if
this host is acting as a gaweway, otherwise they are discarded.
Datagrams addressed to this host are delivered to waiting protocol
modules or user processes. User processes or protocol modules may
create datagrams to be sent, these are queued and based on the
destination address sent via one of the connected network interfaces.
During the processing of arriving datagrams several checks must be
made:
1. check the IP version number
2. verify the checksum
3. see that the length field and the amount received are
consistent (amount received may be slightly greater due to
padding)
4. check time to live
5. assemble fragments
Postel [Page 9]
IEN 121
Internet Meeting Notes
When sending a datagram the IP fills in several fields and makes a
routing decision:
1. Insert source address
2. Insert any IP options called for
3. Insert time to live
4. Insert checksum
5. Make a routing decision, select an output interface, generate
local net header and interpret type of service.
6. Queue for transmission
The routing decision can be based on a table of network - gateway
correspondences. For each network a gateway on a directly connected
network is listed. If the host is notified to use a different
gateway for that destination network the table can be updated. If a
gateway breaks and the host can tell (e.g., receives a "destination
dead" response) then switch to an alternate gateway. It is
suggested that a heuristic for switching destination gateway is to do
it when the higher level protocol (e.g., TCP) retransmits a segment.
(However it is not clear the IP can tell a new transmission from a
retransmission).
In the area of congestion control Bill suggests that it is the rate
that must be controlled which may be considered to determine an
internet datagram interval. If a gateway tells a host to slow down,
increase the internet datagram interval to, say, 130% of its former
value. To avoid being stuck at a too large value for the internet
datagram interval, reduce it to 95% of its former value every 30
seconds or so.
There is an issue of fairness in any congestion control. How can the
IP properly allocate the available transmission capacity among the
higher level protocol modules and users?
The discussion suggested the need for a "Trace Datagram" that causes
each gateway and the destination host to send back a note, a kind of
"multi-echo."
IP modules should provide a handle on the user side to explicitly
cause a new routing to be calculated.
The congestion control parameters may be very critical and sensitive.
Dave Clark has done some simulation experiments and will prepare an
IEN on this topic. There may be some interaction between
source-destination host pairs in this area.
Postel [Page 10]
IEN 121
Internet Meeting Notes
VIII. STREAMS AND CONFERENCING - Forgie
Jim presented the proposed ST protocol which is documented in IEN
119. The goals of ST are: (1) to provide a good base for
point-to-point and conference packet speech, (2) to support research
on effective traffic control techniques, (3) to support a
demonstration of cost-effective speech, and (4) to operate as an
extension of internet protocol.
Jim indicated four requirements and corresponding approaches for
meeting them: (1) guaranteed data rate - know requirement in advance
and assign loads to links statistically, (2) controlled delay
(predictable dispersion) - prevent congestion by controlling access
on a call basis, (3) small quantity of speech per packet - use
abbreviated header and aggregate small packets for efficiency, and
(4) efficiency equal to or better than circuit switching without TASI
(packet efficiency * link utilization > 45%) - abbreviated headers
for packet efficiency and high link utilization with effective
traffic control.
One of the key decisions is to consider ST connections to be full
duplex. The claim is made that this allows faster connection setup
for conferences. There was some discussion on this point and the
issue will be examined further.
Another issue is the sharing of transmission capacity between speech
(ST) and data (IP) in the internet.
Also discussed was the identification of the route by a list of
gateways rather than by a list of networks. The resources to be
reserved are controlled by networks not gateways.
One very interesting feature of ST is its mechanism for flexible
multi-addressing and routing of messages such that each addressee
receives at most one copy of a message.
Jim presented the message formats and worked through an example of
connection setup. There was some concern expressed about the effects
of delayed duplicate control messages, and how ST operates under
failure conditions. Also concern that several conference setups in
competion may result is a deadlock similar to reassembly lock up.
Postel [Page 11]
IEN 121
Internet Meeting Notes
IX. SOURCE ROUTING & PROTOCOL MULTIPLEXING - Cohen
Danny reviewed the proposed source routing procedure described in
IEN 95. This mechanism provides a list of addresses for the datagram
to pass through. Normal routing is used to move the datagram between
these points. The route information for sending a datagram from A
through B and C to D is expressed by A as TO: B, SR: C,D. At B this
is changed to TO: C, SR: D, and at C it is changed to TO: D. The key
is that the next address must be interpretable at the point it is
used. This means that local (rather than internet) addresses may be
used.
The discussion focused around the issue of non internet addresses in
the source route and how (if at all) to mark them. It seems
desirable to let a source route contain any of the following in any
order:
1. Internet Address.
2. Local Address (prefixed with an escape code and a length).
3. Network Address (Network part only).
4. Here - an address value that means this host, this net (or any
host, or every host).
Alternately one could have each address in the source route have a
prefixed "op-code" that indicates what kind of address it is.
Danny did not discuss the multiplexing of protocols (due to time
pressures) but urged everyone to review IEN 90. It appeared that the
multiplexing protocol was accepted (at least in principle).
X. GATEWAY MONITORING & CONTROL CENTER - Flood Page
David described the GMCC organization and the types of information
that will be reported.
The operation is much like the ARPANET NCC except that gateways are
the objects of interest rather than IMPs.
Gateways will communicate with a set of monitoring and control
processes (running on a TOPS20 somewhere). These monitoring and
control processes will update a central data base. The data in this
data base may be accessed by Terminal Processes (i.e., User Interface
Programs).
A terminal process may take control of a gateway, but a gateway may
only be controlled by one terminal process at a time.
Three types of controls may be exercised: start or stop reports,
inquiries, enable or disable traps. The reports give throughput
Postel [Page 12]
IEN 121
Internet Meeting Notes
statistics and interface up/down status. The inquiries give the
gateway description (name, connectivity), echo response, or routing
data. The traps give changes in the interface up/down status, or
neighbor gateway up/down status.
The information stored for each gateway in the central data base
includes: the latest regular report, the interface address, the
neighbor gateways, the reporting and trap status, the gateways own
up/down status, and the process currently controlling the gateway (if
any).
In the future the GMCC will provide summary reports on traffic and
up/down status.
Other future topics are Performance Measures, Higher Level Fault
Diagnosis, Accounting Information, and inclusion of information from
NCCs.
To use the GMCC facilities one would login to the GMCC host and run a
terminal process. There was some discussion of the access control on
people taking control of gateways. Also some concern about the
artifact introduced into the measurement by accessing the GMCC via
the gateway being measured, and also the effect on other gateways (or
their statistics) of relaying the measurement messages to the GMCC
host.
David will prepare reports on: (1) GMCC Message Formats, (2) How to
use a Terminal Process.
XI. DISCUSSION OF SPEECH DEMO - Forgie
Jim described the configuration for the speech demo. There are four
sites involved: Lincoln Laboratory and ISI on the ARPANET and NDRE
and UCL on the SATNET. There is a special purpose gateway at BBN.
This gateway is a PDP 11/34 ELF system. The basic data rate for one
site is 5 packets/sec, at this rate the gateway must handle 15
packets/sec.
In the ARPANET section of the conference the mode of operation is
centralized control and distributed data. In the SATNET section the
mode is distributed control and distributed data. The SATNET section
uses a SATNET shared stream.
XII. DISCUSSION OF FAX SYSTEM - Treadwell
Steve described the configuration and operation of the FAX-Network
system. The FAX machine is a DACOM 6000. It is connected to an
LSI-11 (MOS operating system). The LSI-11 contains an interface to
Postel [Page 13]
IEN 121
Internet Meeting Notes
the DACOM, a TCP, and a controlling program. The controlling program
interacts with a user at a display terminal.
There is also a server FAX program on BBNC that accepts input and
stores it in the file system, or on request sends stored FAX data
from the file system.
The operation is for the user to type on the controlling programs
terminal a request to send FAX data to a file. A TCP connection is
established between the LSI-11 and FAX server at BBNC.
Pages are input through the DACOM and data is sent to BBNC and stored
in the file. To move FAX data from the file to paper, the user
enters a retrieve request on the controlling programs terminal.
This system currently uses TCP-2.5. The next step will be to convert
to using version 4. Also to change the address so the transmission
will be through an internet gateway.
There have been several problems in getting this working. Primarily
the timing requirements of the DACOM and the flow control of TCP. A
typical page results in 300,000 bits (with wide variance). The DACOM
sends 585 bit blocks and if not accepted with in 6 seconds aborts the
page. The total transmission path must support at least 100 bits/sec
on the long term average.
ISI is getting a RAPICOM 450 FAX machine and will use it in a similar
way. (A RAPICOM 450 and a DACOM 6000 are identical machines). At
ISI the FAX machine will be treated as a device (a peculiar terminal
on TOPS20) rather than as a host.
XIII. ADDRESSING ISSUES - Cerf
Vint described several situations where a host may have several
possible addresses and may wish to change between them dynamically
without losing ongoing communications.
A host may be dual (or multiply) homed, i.e., have two (or more)
interfaces to the same net. A host may be connected to more than one
net. Or a host may change nets.
This last case is illustrated by a flying packet radio, passing over
a series of ground PRNETs each connected to the internet via a
gateway. The flying packet radio is for a time in the range of
PRNET-1, then passes out of that range into the range of PRNET-2,
etc.
Another problem is partitioning. That is a network breaks into two
(or more) parts which continue to function independently. Can a host
Postel [Page 14]
IEN 121
Internet Meeting Notes
in one part communicate with a host in another part via gateways and
other networks?
Does source routing solve the partitioning problem? Or is a scheme
needed to dynamically assign unique addresses to each partition so
that the ordinary gateway dynamic routing will solve the problem?
Another proposal is to drop the requirement that connection be
identified by the total address. By using only the pair of ports to
identify a connection one could accept as a continuation of a
conversation messages from a different host if it had the same pair
of ports (and the expected sequence number).
XIV. PARTITIONING - Plummer
Bill discussed the problems of multiply connected hosts. If a host
is connected to two networks, which are also interconnected via
gateways, the host has alternate routes to use in sending messages.
The internet gateways can exchange connectivity information. A
multiply connected host cannot take full advantage of this without
being a gateway itself and calling the host a network. Another
problem is for a destination to answer a message from a multi-
connected host. The multi-connected host would like to allow any of
its interfaces to be used to receive the reply. To do this it could
use a pseudo network number and act as if those interfaces were
gateway connections.
This use of network numbers for pseudo nets may use up the network
numbers too quickly. Bill proposes what he calls host-group routing
which uses a 32 bit address as if it were a network number. A host
chooses one of its internet addresses as its "name". Gateways treat
that name as a network name for connectivity and routing purposes. A
mask can be used to allow groups of hosts to be routed based on one
entry. Bill gave an example of how this might work and showed a
routing table for a pseudo net at BBNC.
This topic is to be discussed again at the next meeting.
XV. RIG - Lantz
Keith reported on the network environment at the University of
Rochester. The key is a multi-machine multi-net system started in
1974. All communication between processes in this system is via
messages. The system is based on Feldman's experience and other
papers on message communication.
The equipment involved includes: 4 Altos, 2 Eclipses, an Ethernet, 9
terminals, 1 PDP-10, 1 VAX, and an ARPANET. The applications
include: editing, compiling, file management. An important
Postel [Page 15]
IEN 121
Internet Meeting Notes
development is the virtual terminal model, which allows several
processes to interact with a terminal using multiple possibly
overlapping windows.
The process level communication involves a name to address conversion
by lookup in a name server, and an address to route conversion
supported by a local kernel and network communication modules. Three
communication styles are supported: atomic transactions, connections
or streams, and asynchronous messages.
One problem area is protocols. There are too many: U of R Ethernet,
PARC Ethernet, ARPANET, DECNET, internet. Can all these live in
harmony?
XVI. SUMMARY OF SMALL GROUP MEETINGS
1. PERFORMANCE MEASUREMENT SMALL GROUP MEETING - Kunzelman
This group discussed the need for performance measurements of the
internet protocols at all levels. The group reviewed the current
work, discussed performance metrics, measurement tools, and
documentation of measurement methods and results.
The group recommends that specifications of performance measures
for IP and TCP be written, that a set of tests for IP, TCP, and
higher level protocols be defined, and that a bibliography on
performance measurement be prepared.
Please see Appendix C for further detail on this group meeting.
2. UNIX SMALL GROUP MEETING - Cain
Three topics were addressed in the UNIX small group meeting:
1. Use of network UNIX on small PDP-11's
(specifically, the 11/34 and the 11/40).
2. MOS work on UNIX systems.
3. Use of UNIX on VAX machines.
For PDP-11's which do not support the separation of instruction
and data space, incorporating the widely distributed NCP programs
into the UNIX kernel usually produces an object which is barely
small enough to boot, even after greatly reducing various system
parameters. Processes like TCP and Telnet have to share the scarce
remaining space, and are bound to perform poorly because of
swapping. Noel Chiappa is about to obtain, from NOSC, a version of
UNIX which has no disk buffers in the kernel data space, and will
attempt to install the NCP kernel software. Performance of this
Postel [Page 16]
IEN 121
Internet Meeting Notes
version of UNIX is uncertain, but a mailing list (see Appendix A)
has been established for those interested in the outcome.
UCL, MIT, and BBN are all interested in doing MOS work in a UNIX
environment. The problem is that there is a variety of file types
(a.out, .obj, .rel, .lda) which must somehow be combined into an
object which is loadable into an LSI-11, and is understandable by
DDT or a similar debugger. UCL has "C" interfaces to MOS system
calls and some utilities which Noel Chiappa will attempt to put in
a "nice" UNIX environment, and make them available for others. A
mailing list (see Appendix A) was established for those who wish
to follow his progress.
Keith Lantz discussed a meeting with ARPA, Rochester, CMU, and
others associated with ARPA-funded research involving VAX
machines. At the meeting, the decision was made to use UNIX on the
VAX machines, specifically the version of UNIX modified at
Berkeley to take advantage of the VAX paging hardware. The source
of support for the VAX UNIX is not yet named. Rochester and CMU
are both interested in implementing TCP and IP on their VAX
machines. A mailing list (see Appendix A) was established for
those interested.
3. TCP VERSION 4 AND TIU SMALL GROUP MEETING - Haverty
The small group meeting on the status of the new TCP
implementation and TIU also covered some general issues of TCP
support for MOS-based systems in general.
Jim Mathis reported that recent work on the MOS TCP version 4
implementation involved separating the code into individual
modules, to isolate the network- and operating-system-dependent
sections of the code. The major part of the TCP code is now in the
TV4PRO module. Operating system support code exists in TV4MOS or
TV4ELF, depending on the operating system involved. The
"released" versions of this implementation are available on the
SRI-KL machine in the MOS-DEVEL directory, but they will be moved
soon to PKT-LSI-11.
Ongoing work with the TCP involves addition of an internet layer
which will be accessible to user processes using entry points to
be defined. This will occur in a later release of the software,
which is not expected to involve any changes to the TCP interface
to user processes. The internet layer will also implement some of
the gateway-gateway protocol functions.
In addition, the software can be extended to support multiple
hardware interfaces, to permit multi-homing of hosts on multiple
networks. This work however is not yet in progress.
Postel [Page 17]
IEN 121
Internet Meeting Notes
The discussions which followed identified a need for two new
mechanisms within the user community. The first is simply an
announcement mechanism, to inform users of the SRI software of new
releases, the changes which have been made, functions added, and
location of the code itself. A second mechanism involves
integration of changes developed at user sites into the
SRI-maintained sources. For example, software to support other
network types must be done at the site running the network, but
should then be integrated into the standard sources.
Because of the need for sites other than SRI to implement
network-interface software, the internal interface between the TCP
and internet layer and the local-net module must be clearly
defined and stabilized. MIT is likely to be the first site to
implement a new local-net module.
Further discussion explored details of the functionality of the
existing TCP implementation, and requirements which various user
projects expect to have in the future. Some of the facilities
not yet implemented include:
o ability to have multiple connections in one MOS process
o reassembly of internet fragments
o full processing of EOL
o processing of "rubber EOL"
o user access to URGENT functions
o full functionality at the Telnet user interface
The last area explored identified the need for additional work on
the Telnet implementation, to, for example, provide the ability to
send remote RESETs.
A short discussion of "coming attractions" followed, including the
following expected changes:
o internet layer in Bliss, probably by the end of 1979
o use of the internet name server by Telnet
o XNET server within MOS, to debug MOS processes remotely
The TCP software is currently written in MACRO-11. It is a
candidate for conversion to Bliss, but this will not be done until
the Port-expander software is converted.
One possible performance limitation was identified during the
discussion. Currently, data is ACKed when it is accepted by a
user process. Since this can be significantly later than the
actual receipt of the data from the network, throughput might be
improved by modifying the TCP to ACK data on receipt from the
network.
Postel [Page 18]
IEN 121
Internet Meeting Notes
A short discussion of TIU issues identified the need for
determining how many terminals can be supported by a TIU at once,
in two cases. In a heavy-use situation, the limitation on number
of active, high-throughput terminals should be determined. This
number is probably limited by the raw speed of the LSI-11, and may
be increased by conversion to faster hardware such as the
PDP-11/23 when it is available. A second case involves the
limitation on support of low-usage terminals. This limit involves
primarily how many serial interfaces can be connected to the
LSI-11 and configured in the packaging.
The meeting also demonstrated a need for better interchange of
information among the participants and general community of users
of MOS, TIUs, and related hardware and software. A mailing list
is being set up, called MOS-TCP, for this kind of activity (see
Appendix A).
4. LONDON-NORSAR LINE AND SATNET SMALL GROUP MEETING - McNeill
Dale said that loading of the Goonhilly SIMP and the london TIP
over the satellite channel is operational. Monitoring and control
paths exist for all SIMPs; sufficient backup paths exist through
use of the satellite channel and gateways connected to other
SIMPs.
Vint announced that beginning January 1, l980, the NORSAR-SDAC
circuit will become a military circuit for operational data only.
Seismic data traffic from the NORSAR TIP will continue to be sent
on this line.
Funding for the London-NORSAR circuit ceases October 1, 1979.
Peter anticipates that the ARPANET direct connection circuit via
SATNET (line 77 between London and SDAC) will be needed to provide
ARPANET connectivity to the London TIP until some time after
October l980. This circuit will continue to provide ARPANET
service to the Rutherford Lab, EPSS, and the London TIP. The
long-term goal is to have internet service to London only using
the UCL gateway attached to SATNET. Prerequisite is a change of
the London TIP to a host (TCP TIP). The mechanism of internet
loading and support of London machines must be developed.
In conflict with the maintenance of operational service to London
is the introduction and checkout of PSP Terminals, the checkout
and release of new SIMP software, and the checkout and performance
of the NTC demonstration. Hardware and software development will
be restricted to after 1400 EDT, while operational service will be
maintained from 0200 to 1400 EDT, daily.
Postel [Page 19]
IEN 121
Internet Meeting Notes
5. NTC DEMO PLANNING SMALL GROUP MEETING - Mills
The principal results from that meeting were a revised plan for
network connectivity and a change in the way speech would be
handled. Specifically, it was decided that Jim Forgie's software
would be used in the BBN and UCL gateways with the LPCM operated
from Washington via appropriate data lines to the BBN Gateway. Jim
has already made provision for this in the LPCM design, but it has
not been operated in this mode before.
Datagram traffic for the Demo is planned to be sent via
Clarksburg, with a backup to Etam via a backdoor connection via
the Clarksburg SIMP internal gateway and the RCC or other suitable
hack. UCL will participate in the Demo from London with live
speech and fax. Participation by NDRE will depend on a PSP
Terminal being installed there.
Jim mentioned a couple of minor problems with the LPCM hardware.
Correcting these will probably involve sending ROMs to the various
sites. There is a question of Gateway reliability which leaves all
of us nervous
6. IP/TCP FLOW CONTROL SMALL GROUP MEETING - Clark
This meeting was a fairly informal discussion among the
implementors of TCP and gateways. Several topics were discussed.
1) How to manage RFNMs on internet link.
2) A simple simulation of a host responding to quench messages.
3) How to perform quenching experiments, given the current level
of internet operation.
4) Should the TCP-IP or application-TCP interface be
specified/standardized with respect to flow control?
While the discussion was fruitful, no substantial conclusions were
drawn.
7. X.25 GATEWAY SMALL GROUP MEETING - Binder
The purpose of this meeting was to review various factors
impacting the development of an ARPANET/X.25 gateway using an
LSI-11 to provide a 50 Kbps full duplex service. The meeting
basically covered only the issue of hardware interfacing to the
X.25 network. Three different interfaces were discussed: a
byte-interrupt device, a non-DMA packet-interrupt device, and a
full DMA device.
The byte-interrupt interface and related level 2 and 3 X.25
software has been developed by UCL and is now available for use.
Although precise throughput measurements have not yet been made,
Postel [Page 20]
IEN 121
Internet Meeting Notes
experience with the LSI-11/MOS system by meeting attendees
indicated that a byte-interrupt configuration would not achieve 50
Kbps full duplex operation. In particular, measurements by SRI
have indicated a maximum of about 50 Kbps through a looped-back
1822 byte-interrupt interface on a MOS system running only a
message generator (no gateway or second network interface).
The packet-interrupt interface is being developed by RSRE, and
along with level 2 software is expected to be checked out in 6-8
weeks. This interface contains 4K bytes of buffering, shared among
input and output. Operation consists of copying packets between
the interface memory and main memory, with a single interrupt
associated with each packet.
UCL plans to develop a full DMA interface, but this is not
expected to be available until anywhere from 8 to 12 months from
now.
A framing issue presently exists in that both IPSS and Telenet
X.25 networks now use bi-sync framing. However, both are expected
to make HDLC bit-oriented framing available this fall.
8. PORT EXPANDER SMALL GROUP MEETING NOTES - Davies
1. Hardware Delivery Outlook.
SRI has fifteen systems on its order book and enough components
to build only two complete ones at this time. Some of the
hardware bottlenecks are:
a) Boxes from DEC - deliveries up to January '80.
b) Low power Schottky chips for 1822 DMA boards.
c) Cable connectors for 1822 units - Amphenol.
d) Control Panels.
Delivery of port expander units would continue at a slow rate
at least until the end of the year with Vint Cerf nominating
the recipient of each system as it rolls off the production
line.
A postscript on the hardware discussion concerned the
robustness card which may have to be reprogrammed for automatic
loading from nets which are not on the ARPANET. The robustness
card uses UV erasable PROMS. Mathis said that there would be
documentation supplied with the robustness card indicating how
this should be done. The cards themselves were just coming back
from the printed circuit facility and although one or two types
of chip for this board were in short supply, it was hoped that
board delivery would begin at the end of September.
Postel [Page 21]
IEN 121
Internet Meeting Notes
2. Software Developments.
Most of the discussion centered around the new facilities which
would be offered with the SRI supported BLISS-11 version of the
PORT Expander code. Some of these features are:
a) Provision of NOP handling.
b) Provision of IMP padding.
c) Flow control facility.
d) Facility to simulate RFNMs internally.
There were still some open ended problems like what should a
port expander do when the NCP host crashes. One possible
approach is to offer two different solutions to this problem
and select one at configuration time.
Possible release dates for the BLISS-11 version of the port
expander were mid October if Mathis can get an IMP port for
debugging or up to a month after depending on the priority of
the work.
Finally Strazisar joined the meeting for a discussion on
integrating the mini-gateway code and port expander code into
the same machine. Clark suggested that this integration problem
would become almost trivial if someone wrote a null 1822 driver
under MOS which allowed buffers to be passed across the driver
without copying. Strazisar volunteered to take a debugged copy
of Mathis' port expander code and integrate it into the
mini-gateway with an optimistic delivery date of the End of
November.
9. TCP IMPLEMENTATION SMALL GROUP MEETING - Cerf
The discussion focused on the changes to IP required by DCA to
satisfy the DOD security and precedence needs. The existing IP
option for S/P/T does most of what's needed, but in addition the
TOS field will be redefined slightly to be:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |S| |S|S|
| PRC |/|Rel|/|P|
| |D| |R|D|
+-+-+-+-+-+-+-+-+
That is:
Bits 0-2: Precedence
Bit 3: Stream or Datagram
Bits 4-5: Reliability
Bit 6: Speed or Reliability
Postel [Page 22]
IEN 121
Internet Meeting Notes
Bit 7: Speed
This information has to be passed up and down the layers of
protocol. Enforcement of the security and precedence is up to
each host. There needs to be a specification of how to interpret
and implement these functions. Preemption rules must be specified
too, for the higher level protocols.
There was some discussion of the unauthorized use of security and
precedence features. The basic rule is to act on it speedily now
and to log the header of the message so one can ask later if the
originator was authorized.
10. TCP APPLICATIONS SMALL GROUP MEETING - Postel
This group discussed problems in programming application programs
that use TCP. Postel had a problem figuring out how to use the
user/TCP interface (JSYSs) to create a successful TCP using
program. The problem may be with the documentation. Haverty has
the problem that programs don't work but don't crash either.
Clark said his TCP can't tell the user anything more specific than
"it didn't work."
What is needed is better documentation, fault isolation tools, and
user level debugging aids. Also a memo on what is available,
e.g., a traffic generator at BBN-UNIX.
11. ST PROTOCOL SMALL GROUP MEETING - Hoversten
This group first made up a detailed agenda of issues to discuss.
In general the topics included:
Connectivity
Routing
Stability
Protocol Layering
Resource Allocation
Information Exchange
Further discussion of the role of ST in resource allocation is
needed. It is agreed that ST provides a structure to support
multi-addressing and a resource allocation policy.
The relationship of ST to IP is that ST is experimental, will be
implemented at a small number of sites, and will have IP imbedded
in it.
Postel [Page 23]
IEN 121
Internet Meeting Notes
12. 1822 BOARD PROBLEM SMALL GROUP MEETING - Mathis
The problem with 1822 boards is being worked on at SRI. Software
for the TIU which circumvents the problem will be made available.
A hardware fix is being studied.
Postel [Page 24]
IEN 121
Internet Meeting Notes
XVII. AGENDA FOR NEXT TIME
The next meeting is February 4-6 at SRI International in Menlo Park.
Ron Kunzelman is the contact.
Agenda Items:
1. Kirstein, Davies, Frankel - Internet Performance Experience
2. Flood Page - Longterm Gateway Statistics
3. Cerf - Schedule & Milestones Review
4. Forgie - ST Protocol
5. Cohen - ST Performance
6. McQuillan - Internet Routing
7. Cain, McFarland, Cerf - IP/TCP Acceptance Testing
8. Plummer, Tomlinson - Higher Level Protocols FTP & Integration
with TCP
9. Postel - Internet Message Handling Interim FTP Based Multi
Media Supporting
10. Deutsch - BBN - FAX & Text Message System
11. Cerf - Multi Homing & Partitioning
12. Plummer - Host Group Routing
13. Demos:
A. GMCC Monitoring - Flood Page
B. Fault Isolation in TIU - Mathis
C. Internet Message Transport - Postel
Action Items:
1. Milestones - each contractor is to provide a list of
milestones to Cerf. The intention is to quantize tasks and
identify increments in capability. The goal is to make
progress easily detectable. The combined milestones will be
distributed to the internet group, and will be reviewed at the
next meeting.
Postel [Page 25]
IEN 121
Internet Meeting Notes
2. Monthly Reports - each contractor is to provide a monthly
report to Postel. The report should note accomplishments,
progress on milestones, unusual events, problems. A summary
of all reports will be distributed to the internet group.
3. XNET - to be converted to version 4 by Jim Mathis and Ray
Tomlinson.
4. Host IP Document - Bill Plummer is to write an IEN on how to
build a host IP.
5. GMCC - David Flood Page will write an IEN on GMCC message
formats and an IEN on how to use a terminal process .
6. Congestion Control - Dave Clark will write an IEN on
simulation experiments in IP congestion control.
Future Meetings Schedule
1980
FEB - SRI
MAY - MIT
SEP - RSRE
1981
JAN - ISI
MAY - ARPA
SEP -UCL
XVIII. DOCUMENTS DISTRIBUTED
IEN Author Title
--- ------ -----
109 Strazisar How to Build a Gateway
110 Cerf Internet Addressing and Naming in a Tactical
Environment
119 Forgie ST - A Proposed Internet Stream Protocol
Postel [Page 26]
IEN 121
Internet Meeting Notes
XIX. ATTENDEES
Vint Cerf ARPA Cerf@ISIA
Robert E. Kahn ARPA KAHN@ISIA
Dick Binder BBN BINDER@BBNE
Jack Haverty BBN JHAVERTY@BBND
Dale McNeill BBN DMCNEILL@BBNE
David Flood Page BBN DFLOODPAGE@BBNE
William Plummer BBN Plummer@BBNA
Virginia Strazisar BBN STRAZISAR@BBNA
Hoi Y. Chong COMSAT Mills@ISIE
David Mills COMSAT Mills@ISIE
Chip Bumgardner CTEC CHIPS@BBNC
Jack Hammett DARPA-IPT Hammett@ISIA
Ed Cain DCA Cain@EDN-UNIX
Ray McFarland DoD McFARLAND@ISIA
Michel L. Audren French Ministry Observer
Dominique A. Truchetet of Defense Observer
Hubert Zimmerman IRIA HZim@BBNC
Danny Cohen ISI Cohen@ISIB
Jon Postel ISI Postel@ISIB
Estil Hoversten Linkabit Hoversten@ISIA
Noel Chiappa MIT JNC@MIT-AI
Dave Clark MIT Clark@MIT-MULTICS
Jim Forgie Lincoln Lab FORGIE@BBN
Frank Deckelman NAVELEX DECKELMAN@ISIA
Aage Stensby NDRE AAGE@SRI-KA
Andrew Bates RSRE RSRE-T4@ISIA
Brian Davies RSRE RSRE-T4@ISIA
Allan J. Fox RSRE RSRE-T4@ISIA
John Laws RSRE RSRE-T4@ISIA
Ron Kunzelman SRI KUNZELMAN@SRI-KL
Jim Mathis SRI Mathis@SRI-KL
Robert Cole UCL UKSAT@ISIE
Sunil K. Das UCL PKT-UCL@SRI-KL
Peter L. Higginson UCL UKSAT@ISIE
Andrew Hinchley UCL UKSAT@ISIE
Ron Jones UCL UKSAT@ISIE
Peter Kirstein UCL Kirstein@ISIA
Alan J. Mayne UCL UKSAT@ISIE
Steve Treadwell UCL UKSAT@ISIE
David Lloyd UCL/UKMOD LLOYD@ISIA
Keith A. Lantz U of R LANTZ@SRI-KL
Postel [Page 27]
IEN 121
Internet Meeting Notes
APPENDIX A
The following special interest group mailing lists have been set up
by Noel Chiappa at MIT-ML. To use them, send to <group>-PEOPLE at
MIT-ML [or just <group> (DON'T include the "<"'s)].
If you want to be on one or more of these mailing lists please send a
note to Noel, JNC@MIT-AI (not to the whole group).
If you get a message from Person and to a mailing list, DO NOT send
your reply to the mailing list AND Person; the MIT-ML mailer isn't
smart enough to notice and will send duplicate copies to Person.
MOS-UNIX MOS support on UNIX
SMALL-UNIX UNIX on small machines
VAX-UNIX UNIX on VAX
MOS-TCP MOS, TIU and the MACRO-11 TCP
MOS-PE Port expander / Minigateway
NET-UNIX Network support on any UNIX
Postel [Page 28]
IEN 121
Internet Meeting Notes
APPENDIX B
IP and TCP Specification Differences
The following is a brief description of the difference between IEN-80
and IEN-111 (IP), and between IEN-81 and IEN-112 (TCP).
In both cases the new documents are intended to simply be better
documents, and no significant changes to the protocols are intended.
There are many minor changes of wording, punctuation, or spacing, so
that a source compare would catch many many paragraphs in which there
is no significant change. It is intended that the text added (or in
some cases deleted) lead to an easier to understand description of
the protocols.
IP Differences
1. A much more specific description of a fragmentation and
reassembly procedure is included.
2. Some Options are changed or added:
a. Three options are added for use by the BCR protocol.
b. A Stream-ID option is added.
c. The Source Route option is changed to conform with IEN-95.
d. The Return Route option is added to conform with IEN-95.
e. The Error Report option is expanded to have several specific
error codes., and a standardized IP header for error reporting.
TCP Differences
1. Two additional States are introduced in the connection closing
sequence.
2. The EOL sequence number fixup procedure is changed to be based
on remembering the sequence number of the beginning of the most
recent buffer rather that the initial sequence number of the
connection.
3. In many cases the RST is not required to acknowledge that
segment that caused the reset to be generated, and in many cases
it is not necessary to check the ACK value to verify a RST.
Postel [Page 29]
IEN 121
Internet Meeting Notes
APPENDIX C
Minutes of Internet Subgroup Meeting for Performance Measurement
Present: Ron Kunzelman (SRI) (Chairman), Noel Chiappa (MIT),
Brian Davies (RSRE), Stephen Edge (UCL), David Flood Page (BBN),
Andrew Hinchley (UCL), Ron Jones (UCL), Bob Kahn (ARPA), Peter
Kirstein (UCL), Alan Mayne (UCL) (Minute-taker), Ray McFarland
(DOD)
Kunzelman pointed out that there is need for performance
measurement at different levels of protocol, including
measurements on Telnet and FTP at the user level, TCP at the
transport level, and datagrams at the internet level. The meeting
then considered various specific aspects of measurement.
Measurement Work Now Being Done or Being Planned
BBN (Flood Page) will do some performance measurements at the
datagram level on traffic passing through gateways; no tests are
envisaged. The BBN gateway will monitor IP traffic going through
the gateway. BBN is looking at CPU utilization, and can also
extract interface information by address pairs. BBN (Wingfield)
is doing some performance tests on TCP. Throughput and delays
have been investigated.
SRI is measuring Telnet throughput (bits/sec) from TOPS20 and
TENEX hosts.
UCL is trying to time FAX transmissions, and NIFTP transmissions
at the user level. UCL would like to measure individual
performances end-to-end, to see if there is any destructive
interference. For ARPANET-SATNET-ARPANET transmissions, there is
a need to know the best ARPANET performance, the best gateway
performance, and the best Satnet performance, and then compare the
combination of these with the best actual ARPANET-SATNET-ARPANET
performance, to see whether they are comparable or differ by an
order of magnitude.
RSRE (Davies) has previously measured with old PIXIE, and would
now like to repeat some of these measurements with new PIXIE.
Measures have been made of round-trip TCP ack times. The
measurement techniques consist mainly of turning the traffic
generator on for about five minutes at a time, then obtaining a
delay histogram.
Postel [Page 30]
IEN 121
Internet Meeting Notes
Performance Metrics
The following metrics have been used to measure ARPANET
performance:
1. ARPANET has problems of low bandwidth, hence uses
throughput metrics such as packets/sec and user-bits/sec.
2. SATNET has long delays, hence measures mean transmission
time.
3. PRNET is liable to high loss, hence measures the percentage
of missing packets.
4. Packet efficiency is the ratio of information packets
received to total packets received (the difference being
due to control and retransmission overhead).
Kirstein stressed the need for better individual metrics, and then
for developing algorithms for combining them. For example, both
bits/sec and packets/sec are important.
He also raised the question of how the performance varies when
going through different combinations of networks.
Measurement Tools
Tools currently being used in Arpanet include:
1. At the user level, FTP + "stopwatch" for bandwidth and
Telnet + "stopwatch" for measurements of remote echo time and
bandwidth.
2. Timestamps in pickup packets.
3. Echo server in gateways.
4. Traffic generators and sinks.
There is also a possibility of using synchronized clocks to
measure one-way times and asymmetric delays as well as round
trip times. Hinchley is looking at interval times between
successive packet streams, as a method of measuring delays.
Measurement Needs
Kunzelman pointed out that there is currently no measurement at
the transport level in the ARPANET. Statistics are needed for the
distribution of user traffic, which can be measured on entry to
Postel [Page 31]
IEN 121
Internet Meeting Notes
the internet system. There is also a need to have statistics for
the distribution of packet sizes.
More measurement is needed of round-trip TCP ack times: so far,
this has been done only by RSRE. Also in TCP, measurements are
needed of retransmissions and checksum errors. TCP-specific
measures should be separated from general network and gateway
measures, although such separation might be difficult to achieve
in practice.
Mayne would be grateful to anyone who would send him empirical
data that would be useful to help validate his proposed simulation
and theoretical studies, especially on problems of joint
ARPANET-SATNET operation. It was pointed out that McQuillan has a
large amount of empirical data.
Some Problem Areas
Kahn pointed out the need to isolate problem areas, such as
optimization and tuning, for which measurements are needed. Some
of these problems relate to research and development about
networks, including obtaining insights about their behavior,
others are concerned with the operational control of networks, and
there is also the problem of persuading some network users that
they actually have problems!
Kirstein said that a big problem is to put uniform methods of
measurement into the internet environment; this is very difficult
and requires much thought.
Kahn asked if we could do absolute performance measurements, or
whether they are all relative.
Kahn said that measurements could contribute to the understanding
of various problem areas, for example: performance tuning and
other parameter optimization, retransmission strategies,
alternative routing strategies, minimum delays for
interactive-type traffic, cost considerations, robustness and
recoverability.
Mayne mentioned two important incentives for carrying out
comprehensive measurements:
1. Validation of simulation runs and theoretical models.
2. Obtaining insights into what is happening, especially in
network operating problems of crucial practical importance.
Postel [Page 32]
IEN 121
Internet Meeting Notes
Documentation
Mayne said that is would be valuable to prepare a comprehensive
list of all documents relevant to network measurement, including
papers on methods and tools, measurement software and write-ups of
that software, and collections and summaries of actual performance
data. He suggested that each organization participating in the
internet, should contribute relevant entries, and he himself will
prepare an annotated bibliography of relevant UCL literature. He
is also willing to act as a mailbox for collecting information
from the other organizations.
It was pointed out that important documents in this area have been
written by Kleinrock, McQuillan, and Wingfield, and also at UCL.
Recommendations for Further Action
1. Study network performance in relation to types of network
subsystem, including network as a whole, gateways, hosts,
operating systems.
2. Write specifications of performance measures for TCP (it
was suggested that this might be done by Wingfield), user
level protocols, and IP.
3. Define a set of tests for IP, Datagram, TCP, higher level
protocols, etc.
4. More work needs to be done on IP, for example, using GGP
and echo packets and measuring round trip times, also
investigating loss rates including numbers of duplicate packets
and packets out of order.
5. Prepare and adequate bibliography of documents on
performance measurements, and keep it up to date.
Postel [Page 33]