requires the attention of the processor to handle interrupts and
process protocol events, some degradation will occur in the
performance of host applications. The degree of degradation is
largely a feature of the hardware architecture and processing
resources required by the protocol. Other disadvantages that may
appear relate to limited performance on the part of the
communications service. This limited performance is usually a
function of the particular operating system and is most directly
related to the method of interprocess communication provided with the
operating system. In general, the more times a message must be
copied from one area of memory to another, the poorer the
communications software will perform. The method of copying and the
number of copies is often a function of the specific operating
system. For example, copying could be optimized if true shared
memory is supported in the operating system. In this case, a
significant amount of copying can be reduced to pointer-passing.
2.2 User program.
The OSI transport service can be implemented as a user job within any
operating system provided a means of multi-task communications is
available or can be implemented. This approach is almost always a
bad one. Performance problems will usually exist because the
communication task is competing for resources like any other
application program. The only justification for this approach is the
need to develop a simple implementation of the transport service
quickly. The NBS implemented the transport protocol using this
approach as the basis for a transport protocol correctness testing
system. Since performance was not a goal of the NBS implementation,
the ease of development and maintenance made this approach
attractive.
2.3 Independent processing element attached to a system bus.
Implementation of the transport service on an independent processor
that attaches to the system bus may provide substantial performance
improvements over other approaches. As computing power and memory
have become cheaper this approach has become realistic. Examples
include the Intel implementation of iNA-961 on a variety of multibus
boards such as the iSBC 186/51 and the iSXM 554. Similar products
have been developed by Motorola and by several independent vendors of
IBM PC add-ons. This approach requires that the transport software
operate on an independent hardware set running under operating system
code developed to support the communications software environment.
Communication with the application programs takes place across the
system bus using some simple, proprietary vendor protocol. Careful
engineering can provide the application programmer with a standard
interface to the communications processor that is similar to the
interface to the input/output subsystem.
The advantages of this approach are mainly concentrated upon enhanced
performance both for the host applications and the communications
service. Depending on such factors as the speed of the
communications processor and the system bus, data communications
throughput may improve by one or two orders of magnitude over that
available from host operating system integrated implementations.
Throughput for host applications should also improve since the
communications processing and interrupt handling for timers and data
links have been removed from the host processor. The communications
mechanism used between the host and communication processors is
usually sufficiently simple that no real burden is added to either
processor.
The disadvantages for this approach are caused by complexity in
developing the communications software. Software development for the
communications board cannot be supported with the standard operating
system tools. A method of downloading the processor board and
debugging the communications software may be required; a trade-off
could be to put the code into firmware or microcode. The
communications software must include at least a hardware monitor and,
more typically, a small operating system to support such functions as
interprocess communication, buffer management, flow control, and task
synchronization. Debugging of the user to communication subsystem
interface may involve several levels of system software and hardware.
The design of the processing element can follow conventional lines,
in which a single processor handling almost all of the operation of
the protocol. However, with inexpensive processor and memory chips
now available, a multiprocessor design is economically viable. The
diagram below shows one such design, which almost directly
corresponds to the structure of the formal description. There are
several advantages to this design:
1) management of CPU and memory resources is at a minimum;
2) essentially no resource contention;
3) transport connection operation can be written in microcode,
separate from network service handling;
4) transport connections can run with true parallelism;
5) throughput is not limited by contention of connections for CPU
and network access; and
6) lower software complexity, due to functional separation.
Possible disadvantages are greater inflexibility and hardware
complexity. However, these might be offset by lower development
costs for microcode, since the code separation should provide overall
lower code complexity in the TPE and the TPM implementations.
In this system, the TPE instantiates a TPM by enabling its clock.
Incoming Outgoing are passed to the TPMs along the memory bus. TPDUs
TPDUs from a TPM are sent on the output data bus. The user interface
controller accepts connect requests from the user and directs them to
the TPE. The TPE assigns a connection reference and informs the
interface controller to direct further inputs for this connection to
the designated TPM. The shared TPM memory is analogous to the
exported variables of the TPM modules in the formal description, and
is used by the TPE to input TPDUs and other information to the TPM.
In summary, the off-loading of communications protocols onto
independent processing systems attached to a host processor across a
system bus is quite common. As processing power and memory become
cheaper, the amount of software off-loaded grows. it is now typical
to fine transport service available for several system buses with
interfaces to operating systems such as UNIX, XENIX, iRMX, MS-DOS,
and VERSADOS.
Legend: **** data channel
.... control channel
==== interface i/o bus
O channel or bus connection point
user
input
*
*
__________V_________
| user interface | input bus
| controller |=================O==============O=======
|__________________| * *
* * *
* * _______*_______
* * | data buffers|
* * ...| TPM1 |
* * : |_____________|
* * : *
* * : *
_________ _____*__________ ________ __*____:______ *
| TPE | | TPE processor| |shared| | TPM1 | *
|buffers|***| | | TPM1 |***| processor | *
|_______| |______________| | mem. | |____________| *
* : : * |______| : *
* : : * * : *
* : : ***********O***********:********************
* : : memory bus : *
* : : : *
* : :...........................O...........*........
____*_________:___ clock enable *
| network | *
| interface |=========================================O========
| controller | output data bus
|________________|
*
*
V
to network
interface
2.4 Front end processor.
A more traditional approach to off-loading communications protocols
involves the use of a free-standing front end processor, an approach
very similar to that of placing the transport service onto a board
attached to the system bus. The difference is one of scale. Typical
front end p interface locally as desirable, as long as such additions
are strictly local (i.e., the invoking of such services does not
result in the exchange of TPDUs with the peer entity).
The interface between the user and transport is by nature
asynchronous (although some hypothetical implementation that is
wholly synchronous could be conjectured). This characteristic is
due to two factors: 1) the interprocess communications (IPC)
mechanism--used between the user and transport--decouples the
two, and to avoid blocking the user process (while waiting for a
response) requires an asynchronous response mechanism, and 2)
there are some asynchronously-generated transport indications that
must be handled (e.g., the arrival of user data or the abrupt
termination of the transport connection due to network errors).
If it is assumed that the user interface to transport is
asynchronous, there are other aspects of the interface that are also
predetermined. The most important of these is that transport
service requests are confirmed twice. The first confirmation occurs
at the time of the transport service request initiation. Here,
interface routines can be used to identify invalid sequences of
requests, such as a request to send data on a connection that is
not yet open. The second confirmation occurs when the service
request crosses the interface into the transport entity. The entity
may accept or reject the request, depending on its resources and its
assessment of connection (transport and network) status, priority,
service quality.
If the interface is to be asynchronous, then some mechanism must be
provided to handle the asynchronous (and sometimes unexpected)
events. Two ways this is commonly achieved are: 1) by polling, and
2) by a software interrupt mechanism. The first of these can be
wasteful of host resources in a multiprogramming environment, while
the second may be complicated to implement. However, if the
interface is a combination of hardware and software, as in the cases
discussed in Parts 2.3 and 2.4, then hardware interrupts may be
available.
One way of implementing the abstract services is to associate with
each service primitive an actual function that is invoked. Such
functions could be held in a special interface library with other
functions and procedures that realize the interface. Each service
primitive function would access the interprocess communication (IPC)
mechanism as necessary to pass parameters to/from the transport
entity.
The description of the abstract service in IS 8073 and N3756 implies
that the interface must handle TSDUs of arbitrary length. This
situation suggests that it may be useful to implement a TSDU as an
object such as a file-pointer rather than as the message itself. In
this way, in the sending entity, TPDUs can be formed by reading
segments of TPDU-size from the file designated, without regard for
the actual length of the file. In the receiving entity, each new
TPDU could be buffered in a file designated by a file-pointer, which
would then be passed to the user when the EOT arrives. In the formal
description of transport, this procedure is actually described,
although explicit file-pointers and files are not used in the
description. This method of implementing the data interface is not
essentially different from maintaining a linked list of buffers. (A
disk file is arranged in precisely this fashion, although the file
user is usually not aware of the structure.)
The abstract service definition describes the set of parameters
that must be passed in each of the service primitives so that
transport can act properly on behalf of the user. These
parameters are required for the transport protocol to operate
correctly (e.g., a called address must be passed with the
connect request and the connect response must contain a responding
address). The abstract service defintion does not preclude,
however, the inclusion of local parameters. Local parameters may be
included in the implementation of the service interface for use
by the local entity. One example is a buffer management parameter
passed from the user in connect requests and confirms, providing
the transport entity with expected buffer usage estimates. The
local entity could use this in implementing a more efficient
buffer management strategy than would otherwise be possible.
One issue that is of importance when designing and implementing
a transport entity is the provision of a registration mechanism for
transport users. This facility provides a means of identifying to
the transport entity those users who are willing to participate in
communications with remote users. An example of such a user is a
data base management system, which ordinarily responds to connections
requests rather than to initiate them. This procedure of user
identification is sometimes called a "passive open". There are
several ways in which registration can be implemented. One is to
install the set of users that provide services in a table at
system generation time. This method may have the disadvantage of
being inflexible. A more flexible approach is to implement a
local transport service primitive, "listen", to indicate a waiting
user. The user then registers its transport suffix with the
transport entity via the listen primitive. Another possibility is a
combination of predefined table and listen primitive. Other
parameters may also be included, such as a partially or fully
qualified transport address from which the user is willing to
receive connections. A variant on this approach is to
provide an ACTIVE/PASSIVE local parameter on the connect request
service primitive. Part 5 discusses this issue in more detail.
3.2 Flow control.
Interface flow control is generally considered to be a local
implementation issue. However, in order to completely specify the
behavior of the transport entity, it was necessary to include in the
formal description a model of the control of data flow across the
service boundaries of transport. The international standards for
transport and the OSI reference model state only that interface flow
control shall be provided but give no guidance on its features.
The actual mechanisms used to accomplish flow control, which need not
explicitly follow the model in the formal description, are dependent
on the way in which the interface itself is realized, i.e., what
TSDUs and service primitives really are and how the transport entity
actually communicates with its user, its environment, and the network
service. For example, if the transport entity communicates with its
user by means of named (UNIX) pipes, then flow control can be
realized using a special interface library routine, which the
receiving process invokes, to control the pipe. This approach also
entails some consideration for the capacity of the pipe and blocking
of the sending process when the pipe is full (discussed further in
Part 3.3). The close correspondence of this interpretation to the
model is clear. However, such an interpretation is apparently not
workable if the user process and the transport entity are in
physically separate processors. In this situation, an explicit
protocol between the receiving process and the sending process must
be provided, which could have the complexity of the data transfer
portion of the Class 0 transport protocol (Class 2 if flow
controlled). Note that the formal model, under proper
interpretation, also describes this mechanism.
3.3 Interprocess communication.
One of the most important elements of a data communication system is
the approach to interprocess communication (IPC). This is true
because suites of protocols are often implemented as groups of
cooperating tasks. Even if the protocol suites are not implemented
as task groups, the communication system is a funnel for service
requests from multiple user processes. The services are normally
communicated through some interprocess pathway. Usually, the
implementation environment places some restrictions upon the
interprocess communications method that can be used. This section
describes the desired traits of IPC for use in data communications
protocol implementations, outlines some possible uses for IPC, and
discusses three common and generic approaches to IPC.
To support the implementation of data communications protocols, IPC
should possess several desirable traits. First, IPC should be
transaction based. This permits sending a message without the
overhead of establishing and maintaining a connection. The
transactions should be confirmed so that a sender can detect and
respond to non-delivery. Second, IPC should support both the
synchronous and the asynchronous modes of message exchange. An IPC
receiver should be able to ask for delivery of any pending messages
and not be blocked from continuing if no messages are present.
Optionally, the receiver should be permitted to wait if no messages
are present, or to continue if the path to the destination is
congested. Third, IPC should preserve the order of messages sent to
the same destination. This allows the use of the IPC without
modification to support protocols that preserve user data sequence.
Fourth, IPC should provide a flow control mechanism to allow pacing
of the sender's transmission speed to that of the receiver.
The uses of IPC in implementation of data communication systems are
many and varied. A common and expected use for IPC is that of
passing user messages among the protocol tasks that are cooperating
to perform the data communication functions. The user messages may
contain the actual data or, more efficiently, references to the
location of the user data. Another common use for the IPC is
implementation and enforcement of local interface flow control. By
limiting the number of IPC messages queued on a particular address,
senders can be slowed to a rate appropriate for the IPC consumer. A
third typical use for IPC is the synchronization of processes. Two
cooperating tasks can coordinate their activities or access to shared
resources by passing IPC messages at particular events in their
processing.
More creative uses of IPC include buffer, timer, and scheduling
management. By establishing buffers as a list of messages available
at a known address at system initialization time, the potential
exists to manage buffers simply and efficiently. A process requiring
a buffer would simply read an IPC message from the known address. If
no messages (i.e., buffers) are available, the process could block
(or continue, as an option). A process that owned a buffer and
wished to release it would simply write a message to the known
address, thus unblocking any processes waiting for a buffer.
To manage timers, messages can be sent to a known address that
represents the timer module. The timer module can then maintain the
list of timer messages with respect to a hardware clock. Upon
expiration of a timer, the associated message can be returned to the
originator via IPC. This provides a convenient method to process the
set of countdown timers required by the transport protocol.
Scheduling management can be achieved by using separate IPC addresses
for message classes. A receiving process can enforce a scheduling
discipline by the order in which the message queues are read. For
example, a transport process might possess three queues: 1) normal
data from the user, 2) expedited data from the user, and 3) messages
from the network. If the transport process then wants to give top
priority to network messages, middle priority to expedited user
messages, and lowest priority to normal user messages, all that is
required is receipt of IPC messages on the highest priority queue
until no more messages are available. Then the receiver moves to the
next lower in priority and so on. More sophistication is possible by
setting limits upon the number of consecutive messages received from
each queue and/or varying the order in which each queue is examined.
It is easy to see how a round-robin scheduling discipline could be
implemented using this form of IPC.
Approaches to IPC can be placed into one of three classes: 1) shared
memory, 2) memory-memory copying, and 3) input/output channel
copying. Shared memory is the most desirable of the three classes
because the amount of data movement is kept to a minimum. To pass
IPC messages using shared memory, the sender builds a small message
referencing a potentially large amount of user data. The small
message is then either copied from the sender's process space to the
receiver's process space or the small message is mapped from one
process space to another using techniques specific to the operating
system and hardware involved. These approaches to shared memory are
equivalent since the amount of data movement is kept to a minimum.
The price to be paid for using this approach is due to the
synchronization of access to the shared memory. This type of sharing
is well understood, and several efficient and simple techniques exist
to manage the sharing.
Memory-memory copying is an approach that has been commonly used for
IPC in UNIX operating system implementations. To pass an IPC message
under UNIX data is copied from the sender's buffer to a kernel buffer
and then from a kernel buffer to the receiver's buffer. Thus two
copy operations are required for each IPC message. Other methods
might only involve a single copy operation. Also note that if one of
the processes involved is the transport protocol implemented in the
kernel, the IPC message must only be copied once. The main
disadvantage of this approach is inefficiency. The major advantage
is simplicity.
When the processes that must exchange messages reside on physically
separate computer systems (e.g., a host and front end), an
input/output channel of some type must be used to support the IPC.
In such a case, the problem is similar to that of the general problem
of a transport protocol. The sender must provide his IPC message to
some standard operating system output mechanism from where it will be
transmitted via some physical medium to the receiver's operating
system. The receiver's operating system will then pass the message
on to the receiving process via some standard operating system input
mechanism. This set of procedures can vary greatly in efficiency and
complexity depending upon the operating systems and hardware
involved. Usually this approach to IPC is used only when the
circumstances require it.
3.4 Interface to real networks.
Implementations of the class 4 transport protocol have been operated
over a wide variety of networks including: 1) ARPANET, 2) X.25
networks, 3) satellite channels, 4) CSMA/CD local area networks, 5)
token bus local area networks, and 6) token ring local area
networks. This section briefly describes known instances of each use
of class 4 transport and provides some quantitative evaluation of the
performance expectations for transport over each network type.
3.4.1 Issues.
The interface of the transport entity to the network service in
general will be realized in a different way from the user interface.
The network service processor is often separate from the host CPU,
connected to it by a bus, direct memory access (DMA), or other link.
A typical way to access the network service is by means of a device
driver. The transfer of data across the interface in this instance
would be by buffer-copying. The use of double-buffering reduces some
of the complexity of flow control, which is usually accomplished by
examining the capacity of the target buffer. If the transport
processor and the network processor are distinct and connected by a
bus or external link, the network access may be more complicated
since copying will take place across the bus or link rather than
across the memory board. In any case, the network service
primitives, as they appear in the formal description and IS 8073 must
be carefully correlated to the actual access scheme, so that the
semantics of the primitives is preserved. One way to do this is to
create a library of routines, each of which corresponds to one of the
service primitives. Each routine is responsible for sending the
proper signal to the network interface unit, whether this
communication is directly, as on a bus, or indirectly via a device
driver. In the case of a connectionless network service, there is
only one primitive, the N_DATA_request (or N_UNIT_DATA_request),
which has to be realized.
In the formal description, flow control to the NSAP is controlled by
by a Slave module, which exerts the "backpressure" on the TPM if its
internal queue gets too long. Incoming flow, however, is controlled
in much the same way as the flow to the transport user is controlled.
The implementor is reminded that the formal description of the flow
control is specified for completeness and not as an implementation
guide. Thus, an implementation should depend upon actual interfaces
in the operating environment to realize necessary functions.
3.4.2 Instances of operation.
3.4.2.1 ARPANET
An early implementation of the class 4 transport protocol was
developed by the NBS as a basis for conformance tests [NBS83]. This
implementation was used over the ARPANET to communicate between NBS,
BBN, and DCA. The early NBS implementation was executed on a
PDP-11/70. A later revision of the NBS implementation has been moved
to a VAX-11/750 and VAX-11/7;80. The Norwegian Telecommunication
Administration (NTA) has implemented class 4 transport for the UNIX
BSD 4.2 operating system to run on a VAX [NTA84]. A later NTA
implementation runs on a Sun 2-120 workstation. The University of
Wisconsin has also implemented the class 4 transport protocol on a
VAX-11/750 [BRI85]. The Wisconsin implementation is embedded in the
BSD 4.2 UNIX kernel. For most of these implementations class 4
transport runs above the DOD IP and below DOD application protocols.
3.4.2.2 X.25 networks
The NBS implementations have been used over Telenet, an X.25 public
data network (PDN). The heaviest use has been testing of class 4
transport between the NBS and several remotely located vendors, in
preparation for a demonstration at the 1984 National Computing
Conference and the 1985 Autofact demonstration. Several approaches
to implementation were seen in the vendors' systems, including ones
similar to those discussed in Part 6.2. At the Autofact
demonstration many vendors operated class 4 transport and the ISO
internetwork protocol across an internetwork of CSMA/CD and token bus
local networks and Accunet, an AT&T X.25 public data network.
3.4.2.3 Satellite channels.
The COMSAT Laboratories have implemented class 4 transport for
operation over point-to-point satellite channels with data rates up
to 1.544 Mbps [CHO85]. This implementation has been used for
experiments between the NBS and COMSAT. As a result of these
experiments several improvements have been made to the class 4
transport specification within the international standards arena
(both ISO and CCITT). The COMSAT implementation runs under a
proprietary multiprocessing operating system known as COSMOS. The
hardware base includes multiple Motorola 68010 CPUs with local memory
and Multibus shared memory for data messages.
3.4.2.4 CSMA/CD networks.
The CSMA/CD network as defined by the IEEE 802.3 standard is the most
popular network over which the class 4 transport has been
implemented. Implementations of transport over CSMA/CD networks have
been demonstrated by: AT&T, Charles River Data Systems,
Computervision, DEC, Hewlitt-Packard, ICL, Intel, Intergraph, NCR and
SUN. Most of these were demonstrated at the 1984 National Computer
Conference [MIL85b] and again at the 1985 Autofact Conference.
Several of these vendors are now delivering products based on the
demonstration software.
3.4.2.5 Token bus networks.
Due to the establishment of class 4 transport as a mandatory protocol
within the General Motor's manufacturing automation protocol (MAP),
many implementations have been demonstrated operating over a token
bus network as defined by the IEEE 802.4 standard. Most past
implementations relied upon a Concord Data Systems token interface
module (TIM) to gain access to the 5 Mbps broadband 802.4 service.
Several vendors have recently announced boards supporting a 10 Mbps
broadband 802.4 service. The newer boards plug directly into
computer system buses while the TIM's are accessed across a high
level data link control (HDLC) serial channel. Vendors demonstrating
class 4 transport over IEEE 802.4 networks include Allen-Bradley,
AT&T, DEC, Gould, Hewlett-Packard, Honeywell, IBM, Intel, Motorola,
NCR and Siemens.
3.4.2.6 Token ring networks.
The class 4 transport implementations by the University of Wisconsin
and by the NTA run over a 10 Mbps token ring network in addition to
ARPANET. The ring used is from Proteon rather than the recently
finished IEEE 802.5 standard.
3.4.3 Performance expectations.
Performance research regarding the class 4 transport protocol has
been limited. Some work has been done at the University of
Wisconsin, at NTA, at Intel, at COMSAT, and at the NBS. The material
presented below draws from this limited body of research to provide
an implementor with some quantitative feeling for the performance
that can be expected from class 4 transport implementations using
different network types. More detail is available from several
published reports [NTA84, BRI85, INT85, MIL85b, COL85]. Some of the
results reported derive from actual measurements while other results
arise from simulation. This distinction is clearly noted.
3.4.3.1 Throughput.
Several live experiments have been conducted to determine the
throughput possible with implementations of class 4 transport.
Achievable throughput depends upon many factors including: 1) CPU
capabilities, 2) use or non-use of transport checksum, 3) IPC
mechanism, 4) buffer management technique, 5) receiver resequencing,
6) network error properties, 7) transport flow control, 8) network
congestion and 9) TPDU size. Some of these are specifically
discussed elsewhere in this document. The reader must keep in mind
these issues when interpreting the throughput measures presented
here.
The University of Wisconsin implemented class 4 transport in the UNIX
kernel for a VAX-11/750 with the express purpose of measuring the
achievable throughput. Throughputs observed over the ARPANET ranged
between 10.4 Kbps and 14.4 Kbps. On an unloaded Proteon ring local
network, observed throughput with checksum ranged between 280 Kbps
and 560 Kbps. Without checksum, throughput ranged between 384 Kbps
and 1 Mbps.
The COMSAT Laboratories implemented class 4 transport under a
proprietary multiprocessor operating system for a multiprocessor
68010 hardware architecture. The transport implementation executed
on one 68010 while the traffic generator and link drivers executed on
a second 68010. All user messages were created in a global shared
memory and were copied only for transmission on the satellite link.
Throughputs as high as 1.4 Mbps were observed without transport
checksumming while up to 535 Kbps could be achieved when transport
checksums were used. Note that when the 1.4 Mbps was achieved the
transport CPU was idle 20% of the time (i.e., the 1.544 Mbps
satellite link was the bottleneck). Thus, the transport
implementation used here could probably achieve around 1.9 Mbps user
throughput with the experiment parameters remaining unchanged.
Higher throughputs are possible by increasing the TPDU size; however,
larger messages stand an increased chance of damage during
transmission.
Intel has implemented a class 4 transport product for operation over
a CSMA/CD local network (iNA-960 running on the iSBC 186/51 or iSXM
552). Intel has measured throughputs achieved with this combination
and has published the results in a technical analysis comparing
iNA-960 performance on the 186/51 with iNA-960 on the 552. The CPU
used to run transport was a 6 MHz 80186. An 82586 co-processor was
used to handle the medium access control. Throughputs measured
ranged between 360 Kbps and 1.32 Mbps, depending on the parameter
values used.
Simulation of class 4 transport via a model developed at the NBS has
been used to predict the performance of the COMSAT implementation and
is now being used to predict the performance of a three processor
architecture that includes an 8 MHz host connected to an 8 MHz front
end over a system bus. The third processor provides medium access
control for the specific local networks being modeled. Early model
results predict throughputs over an unloaded CSMA/CD local network of
up to 1.8 Mbps. The same system modeled over a token bus local
network with the same transport parameters yields throughput
estimates of up to 1.6 Mbps. The token bus technology, however,
permits larger message sizes than CSMA/CD does. When TPDUs of 5120
bytes are used, throughput on the token bus network is predicted to
reach 4.3 Mbps.
3.4.3.2 Delay.
The one-way delay between sending transport user and receiving
transport user is determined by a complex set of factors. Readers
should also note that, in general, this is a difficult measure to
make and little work has been done to date with respect to expected
one-way delays with class 4 transport implementations. In this
section a tutorial is given to explain the factors that determine the
one-way delay to be expected by a transport user. Delay experiments
performed by Intel are reported [INT85], as well as some simulation
experiments conducted by the NBS [MIL85a].
The transport user can generally expect one-way delays to be
determined by the following equation.
D = TS + ND + TR + [IS] + [IR] (1)
where:
[.] means the enclosed quantity may be 0
D is the one-way transport user delay,
TS is the transport data send processing time,
IS is the internet datagram send processing time,
ND is the network delay,
IR is the internet datagram receive processing
time, and
TR is the transport data receive processing time.
Although no performance measurements are available for the ISO
internetwork protocol (ISO IP), the ISO IP is so similar to the DOD
IP that processing times associated with sending and receiving
datagrams should be the about the same for both IPs. Thus, the IS
and IR terms given above are ignored from this point on in the
discussion. Note that many of these factors vary depending upon the
application traffic pattern and loads seen by a transport
implementation. In the following discussion, the transport traffic
is assumed to be a single message.
The value for TS depends upon the CPU used, the IPC mechanism, the
use or non-use of checksum, the size of the user message and the size
of TPDUs, the buffer management scheme in use, and the method chosen
for timer management. Checksum processing times have been observed
that include 3.9 us per octet for a VAX-11/750, 7.5 us per octet on a
Motorola 68010, and 6 us per octet on an Intel 80186. The class 4
transport checksum algorithm has considerable effect on achievable
performance. This is discussed further in Part 7. Typical values for
TS, excluding the processing due to the checksum, are about 4 ms for
CPUs such as the Motorola 68010 and the Intel 80186. For 1024 octet
TPDUs, checksum calculation can increase the TS value to about 12 ms.
The value of TR depends upon similar details as TS. An additional
consideration is whether or not the receiver caches (buffers) out of
order TPDUs. If so, the TR will be higher when no packets are lost
(because of the overhead incurred by the resequencing logic). Also,
when packets are lost, TR can appear to increase due to transport
resequencing delay. When out of order packets are not cached, lost
packets increase D because each unacknowledged packet must be
retransmitted (and then only after a delay waiting for the
retransmission timer to expire). These details are not taken into
account in equation 1. Typical TR values that can be expected with
non-caching implementations on Motorola 68010 and Intel 80186 CPUs
are approximately 3 to 3.5 ms. When transport checksumming is used
on these CPUs, TR becomes about 11 ms for 1024 byte TPDUs.
The value of ND is highly variable, depending on the specific network
technology in use and on the conditions in that network. In general,
ND can be defined by the following equation.
ND = NQ + MA + TX + PD + TQ (2)
where:
NQ is network queuing delay,
MA is medium access delay,
TX is message transmission time,
PD is network propagation delay, and
TQ is transport receive queuing delay.
Each term of the equation is discussed in the following paragraphs.
Network queuing delay (NQ) is the time that a TPDU waits on a network
transmit queue until that TPDU is the first in line for transmission.
NQ depends on the size of the network transmit queue, the rate at
which the queue is emptied, and the number of TPDUs already on the
queue. The size of the transmit queue is usually an implementation
parameter and is generally at least two messages. The rate at which
the queue empties depends upon MA and TX (see the discussion below).
The number of TPDUs already on the queue is determined by the traffic
intensity (ratio of mean arrival rate to mean service rate). As an
example, consider an 8 Kbps point-to-point link serving an eight
message queue that contains 4 messages with an average size of 200
bytes per message. The next message to be placed into the transmit
queue would experience an NQ of 800 ms (i.e., 4 messages times 200
ms). In this example, MA is zero. These basic facts permit the
computation of NQ for particular environments. Note that if the
network send queue is full, back pressure flow control will force
TPDUs to queue in transport transmit buffers and cause TS to appear
to increase by the amount of the transport queuing delay. This
condition depends on application traffic patterns but is ignored for
the purpose of this discussion.
The value of MA depends upon the network access method and on the
network congestion or load. For a point-to-point link MA is zero.
For CSMA/CD networks MA depends upon the load, the number of
stations, the arrival pattern, and the propagation delay. For
CSMA/CD networks MA has values that typically range from zero (no
load) up to about 3 ms (80% loads). Note that the value of MA as
seen by individual stations on a CSMA/CD network is predicted (by NBS
simulation studies) to be as high as 27 ms under 70% loads. Thus,
depending upon the traffic patterns, individual stations may see an
average MA value that is much greater than the average MA value for
the network as a whole. On token bus networks MA is determined by the
token rotation time (TRT) which depends upon the load, the number of
stations, the arrival pattern, the propagation delay, and the values
of the token holding time and target rotation times at each station.
For small networks of 12 stations with a propagation delay of 8 ns,
NBS simulation studies predict TRT values of about 1 ms for zero load
and 4.5 ms for 70% loads for 200 byte messages arriving with
exponential arrival distribution. Traffic patterns also appear to be
an important determinant of target rotation time. When a pair of
stations performs a continuous file transfer, average TRT for the
simulated network is predicted to be 3 ms for zero background load
and 12.5 ms for 70% background load (total network load of 85%).
The message size and the network transmission speed directly
determine TX. Typical transmission speeds include 5 and 10 Mbps for
standard local networks; 64 Kbps, 384 Kbps, or 1.544 Mbps for
point-to-point satellite channels; and 9.6 Kbps or 56 Kbps for
public data network access links.
The properties of the network in use determine the values of PD. On
an IEEE 802.3 network, PD is limited to 25.6 us. For IEEE 802.4
networks, the signal is propagated up-link to a head end and then
down-link from the head end. Propagation delay in these networks
depends on the distance of the source and destination stations from
the head end and on the head end latency. Because the maximum network
length is much greater than with IEEE 802.3 networks, the PD values
can also be much greater. The IEEE 802.4 standard requires that a
network provider give a value for the maximum transmission path
delay. For satellite channels PD is typically between 280 and 330
ms. For the ARPANET, PD depends upon the number of hops that a
message makes between source and destination nodes. The NBS and NTIA
measured ARPANET PD average values of about 190 ms [NTI85]. In the
ARPA internet system the PD is quite variable, depending on the
number of internet gateway hops and the PD values of any intervening
networks (possibly containing satellite channels). In experiments on
an internetwork containing a a satellite link to Korea, it was
determined by David Mills [RFC85] that internet PD values could range
from 19 ms to 1500 ms. Thus, PD values ranging from 300 to 600 ms
can be considered as typical for ARPANET internetwork operation.
The amount of time a TPDU waits in the network receive queue before
being processed by the receiving transport is represented by TQ,
similar to NQ in that the value of TQ depends upon the size of the
queue, the number of TPDUs already in the queue, and the rate at
which the queue is emptied by transport.
Often the user delay D will be dominated by one of the components. On
a satellite channel the principal component of D is PD, which implies
that ND is a principal component by equation (2). On an unloaded
LAN, TS and TR might contribute most to D. On a highly loaded LAN,
MA may cause NQ to rise, again implying that ND is a major factor in
determining D.
Some one-way delay measures have been made by Intel for the iNA-960
product running on a 6 MHz 80186. For an unloaded 10 Mbps CSMA/CD
network the Intel measures show delays as low as 22 ms. The NBS has
done some simulations of class 4 transport over 10 Mbps CSMA/CD and
token bus networks. These (unvalidated) predictions show one-way
delays as low as 6 ms on unloaded LANs and as high as 372 ms on
CSMA/CD LANs with 70% load.
3.4.3.3 Response time.
Determination of transport user response time (i.e., two-way delay)
depends upon many of the same factors discussed above for one-way
delay. In fact, response time can be represented by equation 3 as
shown below.
R = 2D + AS + AR (3)
where:
R is transport user response time,
D is one-way transport user delay,
AS is acknowledgement send processing time, and
AR is acknowledgement receive processing time.
D has been explained above. AS and AR deal with the acknowledgement
sent by transport in response to the TPDU that embodies the user
request.
AS is simply the amount of time that the receiving transport must
spend to generate an AK TPDU. Typical times for this function are
about 2 to 3 ms on processors such as the Motorola 68010 and the
Intel 80186. Of course the actual time required depends upon factors
such as those explained for TS above.
The amount of time, AR, that the sending transport must spend to
process a received AK TPDU. Determination of the actual time
required depends upon factors previously described. Note that for AR
and AS, processing when the checksum is included takes somewhat
longer. However, AK TPDUs are usually between 10 and 20 octets in
length and therefore the increased time due to checksum processing is
much less than for DT TPDUs.
No class 4 transport user response time measures are available;
however, some simulations have been done at the NBS. These
predictions are based upon implementation strategies that have been
used by commercial vendors in building microprocessor-based class 4
transport products. Average response times of about 21 ms on an
unloaded 10 Mbps token bus network, 25 ms with 70% loading, were
predicted by the simulations. On a 10 Mbps CSMA/CD network, the
simulations predict response times of about 17 ms for no load and 54
ms for a 70% load.
3.5 Error and status reporting.
Although the abstract service definition for the transport protocol
specifies a set of services to be offered, the actual set of
services provided by an implementation need not be limited to
these. In particular, local status and error information can be
provided as a confirmed service (request/response) and as an
asynchronous "interrupt" (indication). One use for this service is
to allow users to query the transport entity about the status of
their connections. An example of information that could be
returned from the entity is:
o connection state
o current send sequence number
o current receive and transmit credit windows
o transport/network interface status
o number of retransmissions
o number of DTs and AKs sent and received
o current timer values
Another use for the local status and error reporting service is for
administration purposes. Using the service, an administrator can
gather information such as described above for each open connection.
In addition, statistics concerning the transport entity as a whole
can be obtained, such as number of transport connections open,
average number of connections open over a given reporting period,
buffer use statistics, and total number of retransmitted DT TPDUs.
The administrator might also be given the authority to cancel
connections, restart the entity, or manually set timer values.
4 Entity resource management.
4.1 CPU management.
The formal description has implicit scheduling of TPM modules, due to
the semantics of the Estelle structuring principles. However, the
implementor should not depend on this scheduling to obtain optimal
behavior, since, as stated in Part 1, the structures in the formal
description were imposed for purposes other than operational
efficiency.
Whether by design or by default, every implementation of the
transport protocol embodies some decision about allocating the CPU
resource among transport connections. The resource may be
monolithic, i.e. a single CPU, or it may be distributed, as in the
example design given in Part 2.3. In the former, there are two
simple techniques for apportioning CPU processing time among
transport connections. The first of these,
first-come/first-served, consists of the transport entity handling
user service requests in the order in which they arrive. No
attempt is made to prevent one transport connection from using
an inordinate amount of the CPU.
The second simple technique is round-robin scheduling of
connections. Under this method, each transport connection is
serviced in turn. For each connection, transport processes one
user service request, if there is one present at the interface,
before proceeding to the next connection.
The quality of service parameters provided in the connection request
can be used to provide a finer-grained strategy for managing the CPU.
The CPU could be allocated to connections requiring low delay more
often while those requiring high throughput would be served less
often but for longer periods (i.e., several connections requiring
high throughput might be serviced in a concurrent cluster).
For example, in the service sequence below, let "T" represent
m > 0 service requests, each requiring high throughput, let "D"
represent one service request requiring low delay and let the suffix
n = 1,2,3 represent a connection identifier, unique only within a
particular service requirement type (T,D). Thus T1 represents a set
of service requests for connection 1 of the service requirement type
T, and D1 represents a service set (with one member) for connection 1
of service requirement type D.
D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1...
If m = 4 in this service sequence, then service set D1 will get
worst-case service once every seventh service request processed.
Service set T1 receives service on its four requests only once in
fourteen requests processed.
D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1...