cases of very high priority.
Robustness--The system must not fail or suffer much loss of capability
because of unpredicted situations, unexpected loads, or misuse. An
international crisis is the strongest test of robustness, since the
system must operate immediately and with virtually full performance
when an international situation flares up unexpectedly.
Availability--Elements of the system needed for operational readiness
or fighting must be continuously available.
Interoperability--Different elements of the Department must be able to
"talk" to one another, often in unpredicted ways between parties that
had not planned to interoperate.
These operational needs reflect themselves into five technical or
managerial needs:
1. Functional and operational specifications (that is, will the
protocol designs meet the operational needs?);
2. Maximum interoperability;
3. Minimum procurement, development, and support costs;
4. Ease of transition to new protocols; and
5. Manageability and responsiveness to changing DOD requirements.
These are the criteria against which DOD options for using the ISO
transport and internet protocols should be evaluated.
National Research Council [Page 5]
RFC942 February 1985
Report Transport on Protocols
Performance and Functionality
The performance and functionality of the protocols must provide for
the many unique operational needs of the DOD. The following
paragraphs discuss in some detail both these needs and the ways they
can impact protocol design.
Survivability includes protecting assets, hiding them, and duplicating
them for redundancy. It also includes endurance--the assurance that
those assets that do survive can continue to perform in a battle
environment for as long as needed (generally months rather than
hours); restoral--the ability to restore some of the damaged assets to
operating status; and reconstitution--the ability to integrate
fragmented assets into a surviving and enduring network.
The DOD feels that an important reason for adopting international and
commercial standards is that under cases of very widespread damage to
its own communications networks, it would be able to support DOD
functions by using those civil communications that survive. This
would require interoperability up to the network layer, but neither
TCP nor TP-4 would be needed. The committee has not considered the
extent to which such increased interoperability would increase
survivability through better restoral and reconstitution.
Availability is an indication of how reliable the system and its
components are and how quickly they can be repaired after a failure.
Availability is also a function of how badly the system has been
damaged. The DDN objective for system availability in peacetime varies
according to whether subscribers have access to l or 2 nodes of the
DDN. For subscribers having access to only one node of the DDN, the
objective is that the system be available 99.3 percent of the time,
that is, the system will be unavailable for no more than 60 hours per
year. For subscribers having access to 2 nodes, the objective is that
the system be available 99.99 percent of the time, that is, the system
will be unavailable for no more than one hour per year.
Robustness is a measure of how well the system will operate
successfully in face of the unexpected. Robustness attempts to avoid
or minimize system degradation because of user errors, operator
errors, unusual load patterns, inadequate interface specifications,
and so forth. A well designed and tested system will limit the damage
caused by incorrect or unspecified inputs to affect only the
performance of the specific function that is requested. Since
protocols are very complex and can be in very many "states",
robustness is an important consideration in evaluating and
implementing protocols.
Security attempts to limit the unauthorized user from gaining both the
information communicated in the system and the patterns of traffic
throughout the system. Security also attempts to prevent spoofing of
the system: an agent attempting to appear as a legitimate user,
insert false traffic, or deny services to users by repeatedly seeking
system services.
National Research Council [Page 6]
RFC942 February 1985
Report Transport on Protocols
Finally, Security is also concerned with making sure that electronic
measures cannot seriously degrade the system, confuse its performance,
or cause loss of security in other ways.
Encryption of communication links is a relatively straightforward
element of security. It is widely used, fairly well understood,
constantly undergoing improvement, and becoming less expensive. On
the other hand, computer network security is a much newer field and
considerably more complex. The ability of computer network protocols
to provide security is a very critical issue. In the past decade much
has been learned about vulnerability of computer operating systems,
development of trusted systems, different levels of protection, means
of proving that security has been achieved, and ways to achieve
multilevel systems or a compartmented mode. This is a dynamic field,
however, and new experience and analysis will probably place new
requirements on network protocols.
Crisis-performance needs are a form of global robustness. The nature
of a national security crisis is that it is fraught with the
unexpected. Unusual patterns of communication traffic emerge.
Previously unstressed capabilities become critical to national
leaders. Individuals and organizations that had not been
communicating must suddenly have close, secure, and reliable
communications. Many users need information that they are not sure
exists, and if it does, they do not know where it is or how to get it.
The development of widely deployed, interoperable computer networks
can provide important new capabilities for a crisis, particularly if
there is some investment in preplanning, including the higher-level
protocols that facilitate interoperability. Presidential directives
call for this. This will become a major factor in DOD's need for
interoperability with other federal computer networks. The DOD, as
one of the most affected parties, has good reason to be concerned that
its network protocols will stand the tests of a crisis.
In addition, there are performance and functionality features that are
measures of the capability of the network when it is not damaged or
stressed by unexpected situations. Performance includes quantifiable
measures such as time delays, transmission integrity, data rates and
efficiency, throughput, numbers of users, and other features well
understood in computer networks. Equally important is the extent of
functionality: What jobs will the network do for the user?
The DDN has established some performance objectives such as end-to-end
delays for high-precedence and routine traffic, the probability of
undetected errors, and the probability of misdelivered packets. Such
objectives are important to engineer a system soundly. The DOD must
place greater emphasis on more complex performance issues such as the
efficiency with which protocols process and communicate data.
The DOD has stated a need for an effective and robust system for
precedence and preemption. Precedence refers to the ability of the
system to adaptively allocate network resources so that the network
performance is related to the importance of the function being
National Research Council [Page 7]
RFC942 February 1985
Report Transport on Protocols
performed. Preemption refers to the ability of the system to remove
users (at least temporarily) until the needs of the high-priority user
are satisfied. The ARPANET environment in which the protocols were
developed did not emphasize these capabilities, and the current MILNET
does not function as effectively in this regard as DOD voice
networks.
The DOD has also stated a need for connectionless communications and a
broadcast mode. In the majority of network protocols, when two of
more parties communicate, virtual circuits are established between the
communicating parties. (For reliability, additional virtual circuits
may be established to provide an in place backup.) DOD needs a
connectionless mode where the message can be transmitted to one or
more parties without the virtual circuit in order to enhance
survivability; provide a broadcast capability (one sender to many
receivers); and handle imagery, sensor data, and speech traffic
quickly and efficiently.
If intermediate nodes are destroyed or become otherwise unavailable,
there is still a chance that the data can be sent via alternate paths.
The broadcast capability is particularly important in tactical
situations where many parties must be informed almost simultaneously
and where the available assets may be disappearing and appearing
dynamically. The Department of Defense requires an internetting
capability whereby different autonomous networks of users can
communicate with each other.
Interoperability
Presidential and DOD directives place a high priority on
interoperability, which is related to the internetworking previously
discussed.
Interoperability is primarily important at two levels: network access
and applications. To achieve interoperability at the level of network
access,users of backbone communications nets must utilize the same
lower-level protocols that are utilized by the network. Generally
these protocols are layers 1, 2, and 3, up to and including part of
the IP layer. In other words, interoperability for network access
does not depend on either implementation of the transport layer (TP-4
or TCP) or of all of the internet (IP) layer. The primary advantages
of network access interoperability are twofold:
1. Significant economies of scale are possible since the various
users can share the resources of the backbone network including
hardware, software, and development and support costs.
2. Network survivability for all users can be increased
significantly since the network has high redundancy and, as the
threat increases, the redundancy can also be increased.
Interoperability at the applications layer allows compatible users at
different nodes to talk to each other, that is, to share their data,
National Research Council [Page 8]
RFC942 February 1985
Report Transport on Protocols
support each other, and thereby coordinate and strengthen the
management of forces and other assets. Interoperability at the
applications layer can be achieved through the use of specialized
software that performs those functions of higher-layer protocols (such
as TCP or TP-4, file transfer, and virtual terminal) that are needed
by the particular application. If some of the higher-layer transport
and utility protocols have been developed for particular hosts or work
stations, their use greatly reduces development, integration, and
support costs, although with a potential sacrifice of performance.
Interoperability at the applications level, that is, full functional
interoperability, is important to specialized communities of users
such as the logistics, command and control, or research and
development communities. As these different communities utilize the
DDN, they have the advantages of shared network resources. Within each
community there is full functional interoperability but generally
there is much less need for one community to have functional
interoperability with members of another community.
The implementation of TCP or TP-4 within network users, but without
the implementation of higher-level protocols and application
interoperability, is not generally an immediate step in increasing
interoperability. It does have these immediate advantages:
It represents an important step in investing in longer-term
interoperability.
It generally represents an economical near-term investment on which
communities of interest can build their own applications.
It facilitates the development of devices for general network use
such as Terminal Access Controllers (TACs).
Interoperability at the applications level will become increasingly
important among the following communities: Worldwide Military Command
and Control Systems, including systems of subordinate commands;
Department of Defense Intelligence Information Systems; U.S. tactical
force headquarters (fixed and mobile); NATO force headquarters; other
U.S. intelligence agencies; the State Department; and the Federal
Bureau of Investigation and other security agencies.
Although interoperability of applications within the DOD has the
highest priority, it is clear that government wide and international
interoperability will be an objective with increasing priority. The
NATO situation is especially important (6).
-----
(6) Europe has been a major force in the development of ISO standards.
Consistent with this is a NATO commitment to adopt ISO standards so long
as they meet military requirements.
National Research Council [Page 9]
RFC942 February 1985
Report Transport on Protocols
In a somewhat longer time period, DOD will want applications
interoperability with many commercial information services. As
interoperable computer networks become more common, processing and
data services will burgeon in the marketplace. These will include
specialized data bases and analytic capabilities that all large
organizations will need in order to be up-to-date and competitive.
With regard to interoperability at the network level, DOD will want to
be able to utilize commercially available networks for both
survivability and operational effectiveness and economy. In the case
of a major war in Europe, for example, the United States would want to
be able to use surviving PTTs (Postal, Telegraphy, and Telephony
Ministries) for restoral and reconstitution. During peacetime there
will be cases where special DOD needs can be best satisfied with
commercially available capabilities.
As technology continues to provide less expensive, smaller, and more
reliable data processing equipment, computer networks will become
increasingly prevalent at lower levels of the tactical forces--land,
air, and sea. It will be important that these tactical networks be
capable of interoperability with each other (for example, air support
of ground forces) and with headquarters. It is likely that the
tactical network will need a network architecture and protocols that
are different from the ARPA-\and ISO-derived protocols. If so, the
developments will place requirements on the higher-level DOD
protocols.
If the DOD chooses to move from TCP to TP-4, this can be done in
phases for different communities of interest and subnetworks. In this
way if there is difficulty in converting one subnet, the rest of the
network need not be degraded. Also the different subnets will be able
to make the transition at the most suitable time in terms of cost,
risk, and the need to interoperate with other subnets. As a result if
DOD uses TP-4 for some new nets or major upgrade of existing nets,
this will generally not reduce interoperability in the near term
unless interoperability of applications is needed between two
communities. In this case specific interoperability needs may be
satisfied with specialized gateways for mail or data exchange.
The DOD points out that it desires all networks to be interoperable
since it is not possible to predict when one community will need to
communicate with another or use the resources of the other. As
previously indicated, however, unexpected needs for full functional
interoperability can only be met when appropriate higher-layer
software is developed.
Minimize Costs
The Department of Defense seeks to minimize costs of development,
procurement, transition (if it decides to move to ISO protocols), and
support. Generally the objective is to limit life-cycle costs, that
is, the total costs over a 5-to-8-year period with future costs
suitably discounted (10 to 20 percent per year).
National Research Council [Page 10]
RFC942 February 1985
Report Transport on Protocols
The Department of Defense has already made a heavy investment in
protocols, and the investment has paid off in the success of current
protocols operational in many networks. On the other hand, the DOD
acknowledges the potential advantages of using the ISO protocols if
made available as commercially supported products. Development costs
for these protocols can be small since their development cost is
amortized by the commercial vendor over a larger market. Support
costs for these protocols (including minor modifications, integration
into other products, documentation, and training) are also
significantly reduced because of vendor-supplied services. These cost
factors are further discussed in Section IX in terms of the three
options presented in Section VIII.
Ease of Transition and Manageability
Networks must be manageable and capable of growth and improvement. The
Department of Defense generally makes the fastest progress in
developing complex information systems if it evolves these
capabilities while working in concert with the users and the acquiring
agencies. In this light, the following factors are important:
Minimal interruption of current service--For most DOD networks it is
essential that they operate continuously. If there is to be
transition to new protocol services (whether based on current DOD
versions or ISO), it is important that these transitions be planned,
designed, and pretested so that the transition will be nondisruptive.
Verifiability--It is essential to have a testing capability where new
protocol implementations can be thoroughly tested to ensure that they
will interoperate, have full functionality specified, do not contain
errors, are robust, and meet quantitative performance needs. The
National Bureau of Standards has established such a capability, and
it is being used to verify a number of TP-4 implementations,
including those demonstrated at the National Computer Conference in
July 1984. An IP-testing capability is being added. The Department
of Defense is planning a similar protocol test facility for TCP, but
work is just getting underway. If the DOD plans to migrate promptly
to TP-4, there is a question whether this investment is warranted.
Compatibility with higher protocols--As the transport and
lower-protocol layers evolve, it is essential that they maintain full
compatibility with higher-layer protocols. This is particularly
important for the DOD because it will increasingly have
inter-operability at the applications level.
Responsiveness to evolving DOD needs--Current DOD needs will change
or new needs may arise. It is very likely, for example, that subtle
performance problems may be discovered in a protocol that are unique
to the strenuous DOD-operating environment and that could have
serious operational consequences. If the DOD is using commercial
protocols products based upon international standards, the DOD will
need two commitments when critical deficiencies are discovered. It
will need a commitment from the manufacturer that critical problems
National Research Council [Page 11]
RFC942 February 1985
Report Transport on Protocols
will be promptly fixed and a commitment from the NBS that it will
move quickly to change federal standards and seek changes in
international standards.
Minimal risks--The DOD needs are so large and important, it cannot
afford to take otherwise avoidable risks.
Maintenance of manageability--The DDN is new and is using a new
approach after the cancellation of AUTODIN II (7). There are
pressing operational needs and many impatient users. If the DOD
delays in moving to ISO protocols and later decides to do so, the
costs and disruption will be large. On the other hand, moving now to
ISO will be less disruptive.
-----
(7) AUTODIN II was a program to develop a data communications system
for the DOD. The program envisioned relatively few large packet
switches. It was cancelled in 1982 in favor of ARPANET-derived designs
because of considerations of security, architecture, survivability, and
cost.
National Research Council [Page 12]
RFC942 February 1985
Report Transport on Protocols
III. COMPARISON OF DOD AND ISO PROTOCOLS
This section presents a general description of the major functional
differences between the ISO and DOD protocol sets at the transport and
network layers and then discusses particular aspects of the protocols:
performance, security, and risk.
COMPARISON OF DOD AND ISO TRANSPORT LAYERS
Differences between the Defense Department's TCP protocol and the
International Standards Organization's TP-4 protocol are described in
terms of items visible to users of the protocol. Internal differences
in mechanism that have no effect on the service seen by the user are not
considered. A second much simpler protocol, the User Datagram Protocol
(UDP), providing datagram or connectionless service at the transport
layer is also briefly considered.
In summary, the services provided by TCP and TP-4 are functionally quite
similar. Several functions, however, including data transfer interface,
flow control, connection establishment binding, and out-of-band signals
are provided in significantly different ways by the two protocols.
Neither seems intrinsically superior, but some effort would be required
to convert a higher-level protocol using TCP to make use of TP-4. The
exact amount of work needed will vary with the nature of the
higher-level protocol implementations and the operating systems in which
they are embedded. A programmer experienced with the higher-level
protocols would require about six months to design, implement, and test
modifications of the three major DOD higher-level protocols (file
transfer, mail, and Telnet) to work with TP-4.
There are several areas in which the openness and lack of experience
with the TP-4 specification leave questions about just what
functionality is provided and whether incompatibilities are allowed.
These areas include connection-establishment binding, flow control,
addressing, and provision of expedited network service. The best way to
resolve these questions seems to be to implement and test TP-4 in a
military environment and to further specify desired procedures where
there is unwanted latitude allowed by the standard (see the
recommendations section XI).
There is one area in which the NBS-proposed Federal Information
Processing Standard (FIPS) differs from the ISO specification: The FIPS
provides a graceful closing service as in TCP, while the ISO does not.
National Research Council [Page 13]
RFC942 February 1985
Report Transport on Protocols
Data Transfer Interface
TCP is stream oriented. It does not deliver any End of Transmission
(EOT), but accepts a "push" on the send side which has an effect much
like an EOT causes data being buffered to be sent.
TP-4 is block oriented and does deliver EOT indications. By indicating
EOT, a sending user should be able to accomplish the same effect as
"push" in TCP in most reasonable TP-4 implementations.
The impact of this is uncertain. Neither type of interface is
inherently better than the other. Some applications will find it more
convenient to have a stream-type interface (for example, interactive
terminal handling), while others might prefer a block mode (for example,
file transfer). It should be possible for TP-4 to approximate the
stream mode by forwarding data without an EOT from the sending user and
delivering data to the receiving user before an EOT is received. Some
work would have to be done on applications using one type of protocol to
modify them to use the other.
Flow Control
TCP has octet units of allocation, with no EOT and hence no impact of
EOT on the allocation. The segment size, Transport Protocol Data Unit
(TPDU) size, used by the protocol is invisible to the user, who sees
allocations in units of octets.
TP-4 has segment units of allocation, with a common segment size for
both directions negotiated as part of connection establishment.
Although in some implementations the protocol's flow control is not
directly visible to the users, in others it is. In the latter case,
users of TP-4 will see allocations in units of segments and will have to
be aware of the segment size for this to be meaningful (for example, to
know that a window of four 100-byte segments seen will be consumed by
two messages of 101 to 200 bytes each).
The impact is uncertain. Both octet and segment units of flow control
can be argued to have their advantages for different types of
application. The former makes it easy to indicate buffering limits in
terms of total bytes (appropriate for stream transfer), while the latter
makes it easy to indicate buffering limits in terms of messages
(appropriate for block mode). The way in which flow control is exerted
over an interface is complex and one of the most performance-sensitive
areas of protocols, so a significant conversion and tuning effort would
be required to get an application used with one type of high-level
protocol to be able to perform using another.
Error Detection
TCP applies ones-complement addition checksum. TP-4 uses an ISO
National Research Council [Page 14]
RFC942 February 1985
Report Transport on Protocols
algorithm (8). The error-detection properties of the TCP procedure have
not been studied carefully, but the ISO algorithm is thought to be
somewhat stronger and hence allows fewer nondetected errors in data
passed to users. It should be noted that the TCP checksum is defined to
include certain fields from the IP level including addresses so that
double protection against misdelivery errors is provided. The practical
difference in error-detection power is probably not important.
Simultaneous Call Between Same Users
TCP will establish one call. TP-4 will establish two calls if both
sides support multiple calls, no call if they allow only one call (that
is, see each other as busy), or in very unusual circumstances, one call.
The impact is minor since most applications naturally have an initiator
and a responder side.
Multiple Calls Between Same Addresses_
TCP allows only one call between a given pair of source and destination
ports. TP-4 allows more than one by using reference numbers. The
impact is minor since it is easy to generate a new per-call port number
on the calling side in most cases. This can be a problem in TCP,
however, if both are well-known ports.
Addressing
TCP provides sixteen bit ports for addressing within a node identified
by the internet layer. Some of these ports are assigned to well-known
applications, others are free for dynamic assignment as needed.
TP-4 provides a variable-length transport suffix (same as Transport
Service Access Point Identifier) in the call-request packet. The use of
addresses at different levels in the ISO model has not yet been
solidified, but it seems likely that addressing capabilities similar to
TCP's will eventually be provided by TP-4 (or possibly the session
layer) along with standard addresses for common applications.
The impact is likely to be minimal, but this is an open area of the ISO
specifications that may need further definition for use by DOD.
Binding User Entities to Connections
TCP requires a prior Listen Request from a user entity for it to be able
to accept an incoming connection request. Normally a user entity must
exist and declare itself to TCP, giving prior approval to accept
-----
(8) For additional information, see Information Processing Systems,
Open Systems Interconnection, Connection-Oriented Transport Protocol
Specifications, ISO DIS 8073, Section 6.17, page 45.
National Research Council [Page 15]
RFC942 February 1985
Report Transport on Protocols
a call from a specific or general remote entity. In some
implementations it may be possible for a nonresident user entity to
cause a Listen Request to be posted and an instance of the entity to
be created when a matching connection request arrives. TCP does not
queue an incoming connection request with no matching Listen Request
but instead rejects the connection.
TP-4 requires no prior request but passes a Call Indication to a user
entity whenever a Call Request is received. It is, however, left open
as an implementation decision as to how TP-4 finds and/or creates an
appropriate user entity to give the Call Indication; that is, the
service does not include or define how user applications make
themselves available for calls (no Listen Service Primitive). The
implementation guidelines indicate that well-known addresses, prior
process existence, and Call Request queuing are all facilities that
may or may not be provided at the implementor's choice (9). This
would seem to allow for different choices and hence failure to
establish a connection between standard implementations (for example,
caller expects requests not to be queued, while callee does queuing,
and hence never responds).
The practical impact is uncertain due to lack of experience with how
the various options allowed by the TP-4 standard will be used in
practice. TCP seems more oriented to a prior authorization mode of
operation, while TP-4 most easily supports an
indication-with-later-acceptance scenario. It is not clear how TP-4
will support rejecting calls to nonexistent or inactive user entities
and how user entities could control how many calls they would accept.
This area may require DOD refinement.
Out-of-Band Signals
TCP allows the user to specify an urgent condition at any point in the
normal data stream. Several such indications may be combined, with
only the last one shown to the destination. There is no limit to the
number of urgent indications that can be sent. The TCP urgent
messages are sent requesting expedited service from the network layer
so network bottlenecks can be bypassed as well.
TP-4 allows users to send expedited data units carrying up to sixteen
octets of user data. These are only half synchronized with the normal
data stream since they may be delivered before previously sent normal
data, but not after subsequently sent normal data. Each expedited
data unit is delivered to the destination, and only one can be
outstanding at a time. ISO has indicated its intention to allow
transport protocols to use network-level expedited service, but this
-----
(9) Specification of a Transport Protocol for Computer Communications,
Vol. 5: Guidance for the Implementor, Section 2.11.2. National Bureau
of Standards, Institute for Computer Sciences and Technology,
(Washington, D.C.) U.S. Department of Commerce, January 1983.
National Research Council [Page 16]
RFC942 February 1985
Report Transport on Protocols
is not yet defined.
The impact is primarily for applications like terminal traffic
handlers that must deal with interrupt-type signals of various types.
The need to read an arbitrary amount of normal data and recognize
urgent data in the normal stream are difficulties with TCP urgent
service, but it has been used successfully by the Telnet protocol.
The lack of full synchronization of the signal and normal data in TP-4
may require users to insert their own synchronization marks in the
normal data stream [as was the case with the old ARPA Network Control
Program (NCP)], and the limitation of one outstanding signal may be
restrictive. Some effort would be required to convert higher-level
protocols using one transport protocol to using the other.
Security
The committee has determined that the TCP and TP-4 are sufficiently
equivalent in their security-related properties so that no significant
technical points favor the use of one over the other.
The DOD protocol architecture assigns the security-marking function to
the IP layer and provides an 11-byte security option with a defined
coding in the IP header.
TP-4 provides a variable-length security option carried in Call
Request packets. A variable-length security option field is also
provided in the ISO IP. Standard encoding of security markings are
under consideration but not yet defined and accepted.
In addition to these explicit security-marking fields, the existence,
coding, and placement of other header fields have security
implications. If data is encrypted, for example, a checksum is usually
used to determine if the decrypted data is correct, so the strength of
the checksum has security implications.
Precedence
TCP supports precedence by using three bits provided in IP headers of
every packet. TP-4 provides a 2-byte priority option in Call Request
packets. A 2-byte priority option in the ISO IP header is also under
consideration. Currently, no implementations make use of precedence
information (to support preemption, for example). There should be no
impact, therefore, of changing from one protocol to the other.
Type of Service
The types of network service that can be requested via TCP and TP-4
are somewhat different. The impact seems minimal since few networks
do anything with the type of service fields at present with the
exception of DARPA's packet radio and satellite nets. This may become
more important in the future.
National Research Council [Page 17]
RFC942 February 1985
Report Transport on Protocols
Datagram Service
TCP provides only reliable session service. A separate User Datagram
Protocol (UDP) in the DOD architecture supports transaction or
connectionless-type interaction where individual messages are
exchanged. UDP is merely an addition of the port-addressing layer to
the basic datagram service provided by IP. No delivery confirmation
or sequencing is provided (although IP provides fragmentation and
reassembly).
The NBS TP-4 specification originally presented to the committee
provided unit-data-transfer service within the same protocol framework
as sessions (10). This material has since been deleted to bring the
NBS proposal into conformance with ISO work. A separate ISO datagram
protocol similar to UDP has been defined and is expected to become a
draft proposed standard in June 1984.
Closing
TCP provides a graceful closing mechanism that ensures that all data
submitted by users are delivered before the connection is terminated.
The NBS TP-4 provides a similar mechanism, but is not included in the
ISO standard TP-4, which provides only an immediate disconnect
service. Impact is significant if the ISO version is used because
users would then have to add their own graceful termination handshake
if desired.
COMPARISON OF DOD AND ISO INTERNET LAYERS
The internet protocols of DOD and ISO are much more similar to one
another than the transport protocols. This is not surprising since the
Defense Department's IP was used as the basis for the International
Standards Organization's IP. Some reformatting, renaming, and recoding
of fields has been done. Hence not only are the services to higher
layers essentially equivalent, but the protocol mechanisms themselves
are also nearly identical. Due to the format changes, however, the two
protocols are incompatible.
It should be noted that the IP itself forms only part of the internet
layer. For clarity it should also be noted that the internet layer in
ISO is considered to be the top sublayer within the network layer.
In DOD, there is an additional Internet Control Message Protocol (ICMP)
that deals with error conditions, congestion control, and simple
routing updates to host computers. There is also a Gateway-to-Gateway
Protocol (GGP) that deals with internet management and routing updates
for gateways. In the ISO, only the IP itself has so far been
-----
(10) National Bureau of Standards, Specification of a Transport
Protocol for Computer Communications, Vol. 3, Class 4 Protocol,
ICST/HLNP-83-3, February 1983.
National Research Council [Page 18]
RFC942 February 1985
Report Transport on Protocols
considered, while most error reporting, control, and routing functions
are considered "management" functions that remain to be addressed in
the future.
The only significant differences in the IPs themselves are in the areas
of addressing and error reporting. The DOD IP has a fixed-length,
32-bit source and destination addresses (identifying network and host)
plus an 8-bit "protocol number" field to identify the higher-level
protocol for which the IP data is intended. The ISO IP has
variable-length source and destination addresses whose format and
content are not yet specified, although preliminary documentation
indicates that ISO intends to support a similar level of addressing
(network/host) in a more global context which would allow use of
current DOD addresses as a subset. There is no equivalent of the DOD
protocol number field, although possibly the tail of the
variable-length ISO addresses could be used for this purpose.
Error reporting is provided within the ISO IP by means of a separate
packet type, while the DOD provides more complete error- and
status-reporting functions via the separate Internet Control Message
Protocol (ICMP), including routing "redirect" messages to hosts that
have sent datagrams via nonoptimal routes.
In summary, from the functional point of view, DOD and ISO IP can be
considered essentially equivalent with the provision that the
ISO-addressing scheme is suitably resolved. The absence of routing and
control procedures from the ISO internet layer means that additional
procedures beyond IP would be needed to produce a complete,
functioning, internet even if the ISO IP were adopted. It appears that
the existing DOD ICMP and GGP or its successors could be modified to
operate with the ISO IP with modest effort, but this requires further
study and validation in an operational system.
A table at the end of this chapter compares DOD and ISO IP packet
formats.
COMPARISON ON THE BASIS OF PERFORMANCE, SECURITY, AND RISK
Performance
The performance of a transport protocol, such as TCP or TP-4, is a
function of its implementation as well as its inherent design.
Experience in implementing TCP and other proprietary protocols has
demonstrated that implementation considerations usually dominate.
This makes it difficult to compare protocols, since a wide range in
efficiency of implementations is possible. Furthermore, there are a
number of dimensions along which an implementation can be optimized.
Despite the difficulties, protocol designers have developed several
metrics for comparing transport protocols. These view protocol
performance from a variety of perspectives, including (1) user
response time, (2) throughput on a single connection, (3) network and
host computer resource utilization. Protocol efficiency can also be
National Research Council [Page 19]
RFC942 February 1985
Report Transport on Protocols
significantly affected by the communications environment. Protocol
efficiency must be considered in a wide range of communication
environments, including local area networks, satellite links,
terrestrial links, and packet-switched networks.
The critical algorithms most affecting protocol performance are those
that perform end-to-end error control and end-to-end flow control.
These algorithms affect the response time, throughput, and resource
utilization of the protocol during the data transfer phase. The
efficiency of the connection management procedures may also be
important in applications involving frequent connections of brief
duration.
The committee compared the algorithms and message formats specified
for each protocol for critical functions, including flow-and
error-control and connection management. They concluded that since
the two protocols were sufficiently similar there would be no
significant difference in performance of TCP or TP-4 implementations
of equal quality optimized for a given environment.
The committee compared the error-and-flow-control algorithms of TCP/IP
and TP-4. Both employ window-based techniques using large-sequence
number spaces and both permit large window sizes. Their differences
are minor. TCP performs its error-and-flow-control in units of octets,
rather than the protocol data units employed by TP-4. This adds a
small amount of overhead to TCP calculation in return for a finer
control over host buffer memory. The committee did not consider the
difference significant, assuming that appropriate buffer management
strategies are implemented by transport and higher-level protocols.
TP-4 employs more sophisticated techniques to ensure that flow-control
information is reliably transmitted than does TCP. These more
sophisticated techniques may reduce TP-4 protocol overhead during
periods of light load in some applications, possibly adding slightly
more CPU load in other cases. The committee did not consider these
effects significant.
Both protocols employ a three-way handshake for establishing a
transport connection. The differences between the TCP and TP-4
handshake are related to the addressing conventions employed for
establishing connections and do not affect protocol efficiency. In
the common cases where a client process requests a connection to a
server process, the TCP and TP-4 operations are equivalent.
Both protocols permit a range of policy decisions in their
implementation. These include (1) selection of timer values used to
recover from transmission errors and lost packets, (2) selection of
window sizes at the receiver and transmitter, and (3) selection of
protocol data unit sizes. Both permit substantial reduction in
control message overhead by expanding window sizes. Both permit
credits to be granted "optimistically," permitting receiver buffers to
be shared over several transport connections and permitting credit
reduction in the event of buffer congestion. Both permit optimizing
protocol efficiency by delaying control message traffic when it does
National Research Council [Page 20]
RFC942 February 1985
Report Transport on Protocols
not need to be transmitted, combining it with later data or control
traffic.
The most significant difference between TCP and TP-4 flow control
derives from slight differences in expression of flow control at the
transport layer service interface. TCP employs a stream model while
TP-4 uses a message model. These two models are equivalent in
function; however, some higher-level applications protocols may be
more naturally expressed in one model than the other. The committee
considered the possibility that current ARPA protocols might require
some adaptation to operate more efficiently with TP-4. For this
reason the committee recommends that the DOD study the operation of
current DOD higher-level protocols on TP-4 (recommendation 5, Chapter
XI).
Security
The committee considered the impact of security requirements on
transport protocols primarily and also on overall protocol hierarchies
in the DOD, The American National Standards Institute (ANSI), and ISO.
Based on the information the committee received, it finds that:
The current TCP-4 and TP-4 are sufficiently equivalent in their
security-related properties that no significant technical points
would favor the use of one over the other.
There is no technical impediment to their equivalent evolution over
time in the security area.
Risk
There are several risks in implementing a new protocol or protocol
family. These include (1) fatal flaws in protocol design not easily
rectified, (2) errors in protocol specification, (3) ambiguities in
protocol specification, (4) errors in protocol implementation, (5)
performance degradation due to inefficient implementation, (6)
performance degradation due to "untuned" implementation, and (7)
performance degradation due to untuned application protocols.
This list of risks comes from experience in implementing computer
networks based on the DOD protocols and proprietary commercial
protocols. Considering that it took more than ten years for the
current TCP protocols to reach their current state of maturity and
that the TP-4 protocol is only about two years old, the committee
devoted considerable attention to the maturity of TP-4.
Fatal Flaws in Protocol Design
Early ARPANET protocols had a number of "fatal" design errors that
resulted in deadlocks or other serious system failures. Commercial
networks had similar problems in early design phases. The committee
considered the possibility that TP-4 could suffer from similar faults
and concluded that this was unlikely. TP-4 employs design techniques
National Research Council [Page 21]
RFC942 February 1985
Report Transport on Protocols
similar to those of TCP and proprietary transport protocols. The
faults encountered in the ARPANET are now well known. Indeed, the
state of the art in transport protocol design is now quite mature.
The developers of the TP-4 protocol were familiar with the earlier
protocols and their problems.
Errors and Ambiguities in Protocol Specification
Early in the development of TP-4, NBS developed a formal protocol
specification and a test environment based on this specification. A
protocol implementation can be partially compiled automatically from
the formal specification. Other implementations can be tested against
this master implementation. The NBS protocol laboratory was used to
debug the formal specification of TP-4 and is currently being used to
certify other implementations of TP-4. The laboratory has also
developed and employed tools to analyze the specification for possible
problems. The existence of this laboratory and the results obtained
to date led the committee to conclude that there is no substantial
risk associated with the TP-4 protocol specification.
In contrast TCP has only recently received a formal specification. To
the committee's knowledge most existing TCP implementations predate
the formal TCP specification and have not been derived from the formal
specification. In the committee's opinion the formal TCP
specification is likely to have more bugs or ambiguities than the TP-4
specification.
At the present time NBS has developed the only formal specification
for ISO TP-4. ISO is currently developing standards for formal
specification techniques that are similar to those used by NBS. When
these specifications are complete ISO will update the TP-4
specification to include a formal description. In translating the
current informal ISO specification into the formal specification there
is a risk that the ISO specification may be changed such that it is no
longer consistent with the current NBS specification. The National
Bureau of Standards is playing a key role in developing the ISO formal