There are two studies which indicate that, in many cases, 2 is a good
choice for N [COL85, BRI85]. The increased granularity in buffer
management is reasonably small when compared to the credit
allocation, which ranges from 8K to 120K octets in the studies cited.
The benefit is that the number of acknowledgements generated (and
consumed) is cut approximately in half.
8.2.4.1.3 Selective acknowledgement.
Selective acknowledgement is an option that allows misordered data
messages to be confirmed even in the presence of gaps in the received
message sequence. (Note that selective acknowledgement is only
meaningul whe caching out-of-orderdata messags.) The advantage to
using this mechanism is hat i grealy reduces the number of
unnecessary retransmissions, thus saving both computing time and
transmission bandwidth [COL85] (see the discussion in Part 8.2.4.1.1
for more details).
8.2.4.2 Flow control confirmation and fast retransmission.
Flow control confirmation (FCC) is a mechanism of the transport
protocol whereby acknowledgement messages containing critical flow
control information are confirmed. The critical acknowledgement
messages are those that open a closed flow control window and
certain ones that occur subsequent to a credit reduction. In
principle, if these critical messages are lost, proper
resynchroniztion of the flow control relies on the window timer,
which is generally of relatively long duration. In order to reduce
delay in resynchronizing the flow control, the receiving entity can
repeatedly send, within short intervals, AK TPDUs carrying a request
for confirmation of the flow control state, a procedure known as
"fast" retransmission (of the acknowledgement). If the sender
responds with an AK TPDU carrying an FCC parameter, fast
retransmission is halted. If no AK TPDU carrying the FCC parameter
is received, the fast transmission halts after having reached a
maximum number of retransmissions, and the window timer resumes
control of AK TPDU transmission. It should be noted that FCC is an
optional mechanism of transport and the data sender is not required
to respond to a request for confirmation of the flow control state
wih an AK TPDU carrying the FCC parameter.
Some considerations for deciding whether or not to use FCC and fast
retransmisson procedures are as follows:
1) likelihood of credit reduction on a given transport connection;
2) probability of TPDU loss;
3) expected window timer period;
4) window size; and
5) acknowledgement strategy.
At this time, there is no reported experience with using FCC and fast
retransmission. Thus, it is not known whether or not the procedures
produce sufficient reduction of resynchronization delay to warrant
implementing them.
When implementing fast retransmission, it is suggested that the timer
used for the window timer be employed as the fast timer, since the
window is disabled during fast retransmission in any case. This will
avoid having to manage another timer. The formal description
expressed the fast retransmission timer as a separate timer for
clarity.
8.2.4.3 Concatenation of acknowledgement and data.
When full duplex communication is being operated by two transport
entities, data and acknowledgement TPDUs from each one of the
entities travel in the same direction. The transport protocol
permits concatenating AK TPDUs in the same NSDU as a DT TPDU. The
advantage of using this feaure in an implementation is that fewer
NSDUs will be transmitted, and, consequently, fewer total octets will
be sent, due to the reduced number of network headers transmitted.
However, when operating over the IP, this advantage may not
necessarily be recognized, due to the possible fragmentation of the
NSDU by the IP. A careful analysis of the treatment of the NSDU in
internetwork environments should be done to determine whether or not
concatenation of TPDUs is of sufficient benefit to justify its use in
that situation.
8.2.5 Retransmission policies.
There are primarily two retransmission policies that can be
employed in a transport implementation. In the first of these, a
separate retransmission timer is initiated for each data message
sent by the transport entity. At first glance, this approach appears
to be simple and straightforward to implement. The deficiency of
this scheme is that it is inefficient. This derives from two
sources. First, for each data message transmitted, a timer must be
initiated and cancelled, which consumes a significant amount of CPU
processing time [BRI85]. Second, as the list of outstanding
timers grows, management of the list also becomes increasingly
expensive. There are techniques which make list management more
efficient, such as a list per connection and hashing, but
implementing a policy of one retransmission timer per transport
connection is a superior choice.
The second retransmission policy, implementing one retransmission
timer for each transport conenction, avoids some of the
inefficiencies cited above: the list of outstanding timers is
shorter by approximately an order of magnitude. However, if the
entity receiving the data is generating an acknowledgement for
every data message, the timer must still be cancelled and restarted
for each data/acknowledgement message pair (this is an additional
impetus for implementing an Nth acknowledgement policy with N=2).
The rules governing the single timer per connection scheme are
listed below.
1) If a data message is transmitted and the
retransmission timer for the connection is not
already running, the timer is started.
2) If an acknowledgement for previously unacknowledged
data is received, the retransmission timer is restarted.
3) If an acknowledgement message is received for the
last outstanding data message on the connection
then the timer is cancelled.
4) If the retransmission timer expires, one or more
unacknowledged data messages are retransmitted,
beginning with the one sent earliest. (Two
reports [HEA85, BRI85] suggest that the number
to retransmit is one.)
8.3 Protocol control.
8.3.1 Retransmission timer values.
8.3.1.1 Data retransmission timer.
The value for the reference timer may have a significant impact on
the performance of the transport protocol [COL85]. However,
determining the proper value to use is sometimes difficult.
According to IS 8073, the value for the timer is computed using the
transit delays, Erl and Elr, the acknowledgement delay, Ar, and the
local TPDU processing time, x:
T1 = Erl + Elr + Ar + x
The difficulty in arriving at a good retransmission timer value is
directly related to the variability of these factors Of the two,
Erl and Elr are the most susceptible to variation, and therefore have
the most impact on determining a good timer value. The
following paragraphs discuss methods for choosing retransmission
timer values that are appropriate in several network environments.
In a single-hop satellite environment, network delay (Erl or Elr) has
small variance because of the constant propagation delay of about 270
ms., which overshadows the other components of network delay.
Consequently, a fixed retransmission timer provides good performance.
For example, for a 64K bit/sec. link speed and network queue size
of four, 650 ms. provides good performance [COL85].
Local area networks also have constant propagation delay.
However, propagation delay is a relatively unimportant factor in
total network delay for a local area network. Medium access delay
and queuing delay are the significant components of network delay,
and (Ar + x) also plays a significant role in determining an
appropriate retransmission timer. From the discussion presented in
Part 3.4.3.2 typical numbers for (Ar + x) are on the order of 5 - 6.5
ms and for Erl or Elr, 5 - 35 ms. Consequently, a reasonable value
for the retransmission timer is 100 ms. This value works well for
local area networks, according to one cited report [INT85] and
simulation work performed at the NBS.
For better performance in an environment with long propagation
delays and significant variance, such as an internetwork an adaptive
algorithm is preferred, such as the one suggested value for TCP/IP
[ISI81]. As analyzed by Jain [JAI85], the algorithm uses an
exponential averaging scheme to derive a round trip delay estimate:
D(i) = b * D(i-1) + (1-b) * S(i)
where D(i) is the update of the delay estimate, S(i) is the sample
round trip time measured between transmission of a given packet and
receipt of its acknowledgement, and b is a weighting factor
between 0 and 1, usually 0.5. The retransmission timer is
expressed as some multiplier, k, of D. Small values of k cause
quick detection of lost packets, but result in a higher number of
false timeouts and, therefore, unnecessary retransmissions. In
addition, the retransmission timer should be increased
arbitrarily for each case of multiple transmissions; an exponential
increase is suggested, such that
D(i) = c * D(i-1)
where c is a dimensionless parameter greater than one.
The remaining parameter for the adaptive algorithm is the initial
delay estimate, D(0). It is preferable to choose a slightly
larger value than needed, so that unnecessary retransmissions do
not occur at the beginning. One possibility is to measure the round
trip delay during connection establishment. In any case, the
timer converges except under conditions of sustained congestion.
8.3.1.2 Expedited data retransmission timer.
The timer which governs retransmission of expedited data should
be set using the normal data retransmission timer value.
8.3.1.3 Connect-request/confirm retransmission timer.
Connect request and confirm messages are subject to Erl + Elr,
total network delay, plus processing time at the receiving
transport entity, if these values are known. If an accurate estimate
of the round trip time is not known, two views can be espoused in
choosing the value for this timer. First, since this timer
governs connection establishment, it is desirable to minimize delay
and so a small value can be chosen, possibly resulting in unnecessary
retransmissions. Alternatively, a larger value can be used, reducing
the possibility of unnecessary retransmissions, but resulting in
longer delay in connection establishment should the connect request
or confirm message be lost. The choice between these two views is
dictated largely by local requirements.
8.3.1.4 Disconnect-request retransmission timer.
The timer which governs retransmission of the disconnect request
message should be set from the normal data retransmission timer
value.
8.3.1.5 Fast retransmission timer.
The fast retransmission timer causes critical acknowledgement
messages to be retransmitted avoiding delay in resynchronizing
credit. This timer should be set to approximately Erl + Elr.
8.3.2 Maximum number of retransmissions.
This transport parameter determines the maximum number of times a
data message will be retransmitted. A typical value is eight. If
monitoring of network service is performed then this value can be
adjusted according to observed error rates. As a high error rate
implies a high probability of TPDU loss, when it is desirable to
continue sending despite the decline in quality of service, the
number of TPDU retransmissions (N) should be increased and the
retransmission interval (T1) reduced.
8.4 Selection of maximum Transport Protocol data unit size.
The choice of maximum size for TPDUs in negotiation proposals depends
on the application to be served and the service quality of the
supporting network. In general, an application which produces large
TSDUs should use as large TPDUs as can be negotiated, to reduce the
overhead due to a large number of small TPDUs. An application which
produces small TSDUs should not be affected by the choice of a large
maximum TPDU size, since a TPDU need not be filled to the maximum
size to be sent. Consequently, applications such as file transfers
would need larger TPDUs while terminals would not. On a high
bandwidth network service, large TPDUs give better channel
utilization than do smaller ones. However, when error rates are
high, the likelihood for a given TPDU to be damaged is correlated to
the size and the frequency of the TPDUs. Thus, smaller TPDU size in
the condition of high error rates will yield a smaller probability
that any particular TPDU will be lost.
The implementor must choose whether or not to apply a uniform maximum
TPDU size to all connections. If the network service is uniform in
service quality, then the selection of a uniform maximum can simplify
the implementation. However, if the network quality is not uniform
and it is desirable to optimize the service provided to the transport
user as much as possible, then it may be better to determine the
maximum size on an individual connection basis. This can be done at
the time of the network service access if the characteristics of the
subnetwork are known.
NOTE: The maximum TPDU size is important in the calculation of the
flow control credit, which is in numbers of TPDUs offered. If buffer
space is granted on an octet base, then credit must be granted as
buffer space divided by maximum TPDU size. Use of a smaller TPDU
size can be equivalent to optimistic credit allocation and can lead
to the expected problems, if proper analysis of the management is not
done.
9 Special options.
Special options may be obtained by taking advantage of the manner in
which IS 8073 and N3756 have been written. It must be emphasized
that these options in no way violate the intentions of the standards
bodies that produced the standards. Flexibility was deliberately
written into the standards to ensure that they do not constrain
applicability to a wide variety of situations.
9.1 Negotiations.
The negotiation procedures in IS 8073 have deliberate ambiguities in
them to permit flexibility of usage within closed groups of
communicants (the standard defines explicitly only the behavior among
open communicants). A closed group of communicants in an open system
is one which, by reason of organization, security or other special
needs, carries on certain communication among its members which is
not of interest or not accessible to other open system members.
Examples of some closed groups within DOD might be: an Air Force
Command, such as the SAC; a Navy base or an Army post; a ship;
Defense Intelligence; Joint Chiefs of Staff. Use of this
characteristic does not constitute standard behavior, but it does not
violate conformance to the standard, since the effects of such usage
are not visible to non-members of the closed group. Using the
procedures in this way permits options not provided by the standard.
Such options might permit,for example, carrying special protection
codes on protocol data units or for identifying DT TPDUs as carrying
a particular kind of message.
Standard negotiation procedures state that any parameter in a
received CR TPDU that is not defined by the standard shall be
ignored. This defines only the behavior that is to be exhibited
between two open systems. It does not say that an implementation
which recognizes such non-standard parameters shall not be operated
in networks supporting open systems interconnection. Further, any
other type TPDU containing non-standard parameters is to be treated
as a protocol error when received. The presumption here is that the
non-standard parameter is not recognized, since it has not been
defined. Now consider the following example:
Entity A sends Entity B a CR TPDU containing a non-standard
parameter.
Entity B has been implemented to recognize the non-standard parameter
and to interpret its presence to mean that Entity A will be sending
DT TPDUs to Entity B with a special protection identifier parameter
included.
Entity B sends a CC TPDU containing the non-standard parameter to
indicate to Entity A that it has received and understood the
parameter, and is prepared to receive the specially marked DT TPDUs
from Entity A. Since Entity A originally sent the non-standard
parameter, it recognizes the parameter in the CC TPDU and does not
treat it as a protocol error.
Entity A may now send the specially marked DT TPDUs to Entity B and
Entity B will not reject them as protocol errors.
Note that Entity B sends a CC TPDU with the non-standard parameter
only if it receives a CR TPDU containing the parameter, so that it
does not create a protocol error for an initiating entity that does
not use the parameter. Note also that if Entity B had not recognized
the parameter in the CR TPDU, it would have ignored it and not
returned a CC TPDU containing the parameter. This non-standard
behavior is clearly invisible and inaccessible to Transport entities
outside the closed group that has chosen to implement it, since they
are incapable of distinguishing it from errors in protocol.
9.2 Recovery from peer deactivation.
Transport does not directly support the recovery of the transport
connection from a crashed remote transport entity. A partial
recovery is possible, given proper interpretation of the state tables
in Annex A to IS 8073 and implementation design. The interpretation
of the Class 4 state tables necessary to effect this operation is as
follows:
Whenever a CR TPDU is received in the state OPEN, the entity is
required only to record the new network connection and to reset the
inactivity timer. Thus, if the initiator of the original connection
is the peer which crashed, it may send a new CR TPDU to the surviving
peer, somehow communicating to it the original reference numbers
(there are several ways that this can be done).
Whenever a CC TPDU is received in the
state OPEN, the receiver is required only to record the new network
connection, reset the inactivity timer and send either an AK, DT or
ED TPDU. Thus, if the responder for the original connection is the
peer which crashed, it may send a new CC TPDU to the surviving peer,
communicating to it the original reference numbers.
In order for this procedure to operate properly, the situation in a.,
above, requires a CC TPDU to be sent in response. This could be the
original CC TPDU that was sent, except for new reference numbers.
The original initiator will have sent a new reference number in the
new CR TPDU, so this would go directly into the CC TPDU to be
returned. The new reference number for the responder could just be a
new assignment, with the old reference number frozen. In the
situation in b., the originator could retain its reference number (or
assign a new one if necessary), since the CC TPDU should carry both
old reference numbers and a new one for the responder (see below).
In either situation, only the new reference numbers need be extracted
from the CR/CC TPDUs, since the options and parameters will have been
previously negotiated. This procedure evidently requires that the CR
and CC TPDUs of each connection be stored by the peers in nonvolatile
memory, plus particulars of the negotiations.
To transfer the new reference numbers, it is suggested that the a new
parameter in the CR and CC TPDU be defined, as in Part 9.1, above.
This parameter could also carry the state of data transfer, to aid in
resynchronizing, in the following form:
1) the last DT sequence number received by the peer that crashed;
2) the last DT sequence number sent by the peer that
crashed;
3) the credit last extended by the peer that crashed;
4) the last credit perceived as offered by the surviving peer;
5) the next DT sequence number the peer that crashed expects to
send (this may not be the same as the last one sent, if the last
one sent was never acknowledged);
6) the sequence number of an unacknowledged ED TPDU, if any;
7) the normal data sequence number corresponding to the
transmission of an unacknowledged ED TPDU, if any (this is to
ensure the proper ordering of the ED TPDU in the normal data
flow);
A number of other considerations must be taken into account when
attempting data transfer resynchronization. First, the recovery will
be greatly complicated if subsequencing or flow control confirmation
is in effect when the crash occurs. Careful analysis should be done
to determine whether or not these features provide sufficient benefit
to warrant their inclusion in a survivable system. Second,
non-volatile storage of TPDUs which are unacknowledged must be used
in order that data loss at the time of recovery can be minimized.
Third, the values for the retranmsission timers for the communicating
peers must allow sufficient time for the recovery to be attempted.
This may result in longer delays in retransmitting when TPDUs are
lost under normal conditions. One way that this might be achieved is
for the peers to exchange in the original CR/CC TPDU exchange, their
expected lower bounds for the retransmission timers, following the
procedure in Part 9.1. In this manner, the peer that crashed may be
determine whether or not a new connection should be attempted. Fourth,
while the recovery involves directly only the transport peers when
operating over a connectionless network service, recovery when
operating over a connection-oriented network service requires some
sort of agreement as to when a new network connection is to be
established (if necessary) and which peer is responsible for doing
it. This is required to ensure that unnecessary network
connections are not opened as a result of the recovery. Splitting
network connections may help to ameliorate this problem.
9.3 Selection of transport connection reference numbers.
In N3756, when the reference wait period for a connection begins, the
resources associated with the connection are released and the
reference number is placed in a set of frozen references. A timer
associated with this number is started, and when it expires, the
number is removed from the set. A function which chooses reference
numbers checks this set before assigning the next reference number.
If it is desired to provide a much longer period by the use of a
large reference number space, this can be met by replacing the
implementation dependent function "select_local_ref" (page TPE-17 of
N3756) by the following code:
function select_local_ref : reference_type;
begin
last_ref := (last_ref + 1) mod( N+1 ) + 1;
while last_ref in frozen_ref[class_4] do
last_ref := (last_ref + 1) mod( N+1 ) + 1;
select_local_ref := last_ref;
end;
where "last_ref" is a new variable to be defined in declarations
(pages TPE-10 - TPE-11), used to keep track of the last reference
value assigned, and N is the length of the reference number cycle,
which cannot exceed 2**16 - 1 since the reference number fields in
TPDUs are restricted to 16 bits in length.
9.4 Obtaining Class 2 operation from a Class 4 implementation.
The operation of Class 4 as described in IS 8073 logically contains
that of the Class 2 protocol. The formal description, however, is
written assuming Class 4 and Class 2 to be distinct. This was done
because the description must reflect the conformance statement of IS
8073, which provides that Class 2 alone may be implemented.
However, Class 2 operation can be obtained from a Class 4
implementation, which would yield the advantages of lower complexity,
smaller memory requirements, and lower implementation costs as
compared to implementing the classes separately. The implementor
will have to make the following provisions in the transport entity
and the Class 4 transport machine to realize Class 2 operation.
1) Disable all timers. In the formal description, all Class 4
timers except the reference timer are in the Class 4 TPM.
These timers can be designed at the outset to be enabled or
not at the instantiation of the TPM. The reference timer is
in the Transport Entity module (TPE) and is activated by the
TPE recognizing that the TPM has set its "please_kill_me"
variable to "freeze". If the TPM sets this variable instead
to "now", the reference timer for that transport connection is
never started. However, IS 8073 provides that the reference
timer can be used, as a local entity management decision, for
Class 2.
The above procedure should be used when negotiating from Class
4 to Class 2. If Class 2 is proposed as the preferred class,
then it is advisable to not disable the inactivity timer, to
avoid the possibility of deadlock during connection
establishment if the peer entity never responds to the CR
TPDU. The inactivity timer should be set when the CR TPDU is
sent and deactivated when the CC TPDU is received.
2) Disable checksums. This can be done simply by ensuring that
the boolean variable "use_checksums" is always set to "false"
whenever Class 2 is to be proposed or negotiated.
3) Never permit flow control credit reduction. The formal
description makes flow control credit management a function of
the TPE operations and such management is not reflected in the
operation of the TPM. Thus, this provision may be handled by
always making the "credit-granting" mechanism aware of the
class of the TPM being served.
4) Include Class 2 reaction to network service events. The Class
4 handling of network service events is more flexible than
that of Class 2 to provide the recovery behavior
characteristic of Class 4. Thus, an option should be provided
on the handling of N_DISCONNECT_indication and
N_RESET_indication for Class 2 operation. This consists of
sending a T_DISCONNECT_indication to the Transport User,
setting "please_kill_me" to "now" (optionally to "freeze"),
and transitioning to the CLOSED state, for both events. (The
Class 4 action in the case of the N_DISCONNECT is to remove
the network connection from the set of those associated with
the transport connection and to attempt to obtain a new
network connection if the set becomes empty. The action on
receipt of the N_RESET is to do nothing, since the TPE has
already issued the N_RESET_response.)
5) Ensure that TPDU parameters conform to Class 2. This implies
that subsequence numbers should not be used on AK TPDUs, and
no flow control confirmation parameters should ever appear in
an AK TPDU. The checksum parameter is prevented from
appearing by the "false" value of the "use_checksums"
variable. (The acknowledgement time parameter in the CR and
CC TPDUs will not be used, by virtue of the negotiation
procedure. No special assurance for its non-use is
necessary.)
The TPE management of network connections should see to it
that splitting is never attempted with Class 4 TPMs running as
Class 2. The handling of multiplexing is the same for both
classes, but it is not good practice to multiplex Class 4 and
Class 2 together on the same network connection.
10 References.
[BRI85] Bricker, A., L. Landweber, T. Lebeck, M. Vernon,
"ISO Transport Protocol Experiments," Draft Report
prepared by DLS Associates for the Mitre Corporation,
October 1985.
[COL85] Colella, Richard, Marnie Wheatley, Kevin Mills,
"COMSAT/NBS Experiment Plan for Transport Protocol,"
NBS, Report No. NBSIR 85-3141, May l985.
[CHK85] Chernik, C. Michael, "An NBS Host to Front End
Protocol," NBSIR 85-3236, August 1985.
[CHO85] Chong, H.Y., "Software Development and Implementation
of NBS Class 4 Transport Protocol," October 1985
(available from the author).
[HEA85] Heatley, Sharon, Richard Colella, "Experiment Plan:
ISO Transport Over IEEE 802.3 Local Area Network,"
NBS, Draft Report (available from the authors),
October 1985.
[INT85] "Performance Comparison Between 186/51 and 552,"
The Intel Corporation, Reference No. COM,08, January
1985.
[ISO84a] IS 8073 Information Processing - Open Systems
Interconnection - Transport Protocol Specification,
available from ISO TC97/SC6 Secretariat, ANSI,
1430 Broadway, New York, NY 10018.
[ISO84b] IS 7498 Information Processing - Open Systems
Interconnection - Basic Reference Model, available
from ANSI, address above.
[ISO85a] DP 9074 Estelle - A Formal Description Technique
Based on an Extended State Transition Model,
available from ISO TC97/SC21 Secretariat, ANSI,
address above.
[ISO85b] N3756 Information Processing - Open Systems
Interconnection - Formal Description of IS 8073
in Estelle. (Working Draft, ISO TC97/SC6)
[ISO85c] N3279 Information Processing - Open Systems
Interconnection - DAD1, Draft Addendum to IS 8073
to Provide a Network Connection Management
Service, ISO TC97/SC6 N3279, available from
SC6 Secretariat, ANSI, address above.
[JAI85] Jain, Rajendra K., "CUTE: A Timeout Based Congestion
Control Scheme for Digitial Network Architecture,"
Digital Equipment Corporation (available from the
author), March 1985.
[LIN85] Linn, R.J., "The Features and Facilities of Estelle,"
Proceedings of the IFIP WG 6.1 Fifth International
Workshop on Protocol Specification, Testing and
Verification, North Holland Publishing, Amsterdam,
June 1985.
[MIL85a] Mills, Kevin L., Marnie Wheatley, Sharon Heatley,
"Predicting Transport Protocol Performance",
(in preparation).
[MIL85b] Mills, Kevin L., Jeff Gura, C. Michael Chernik,
"Performance Measurement of OSI Class 4 Transport
Implementations," NBSIR 85-3104, January 1985.
[NAK85] Nakassis, Anastase, "Fletcher's Error Detection
Algorithm: How to Implement It Efficiently and
How to Avoid the Most Common Pitfalls," NBS,
(in preparation).
[NBS83] "Specification of a Transport Protocol for
Computer Communications, Volume 3: Class 4
Protocol," February 1983 (available from
the National Technical Information Service).
[NTA84] Hvinden, Oyvind, "NBS Class 4 Transport Protocol,
UNIX 4.2 BSD Implementation and User Interface
Description," Norwegian Telecommunications
Administration Establishment, Technical Report
No. 84-4053, December 1984.
[NTI82] "User-Oriented Performance Measurements on the
ARPANET: The Testing of a Proposed Federal
Standard," NTIA Report 82-112 (available from
NTIA, Boulder CO)
[NTI85] "The OSI Network Layer Addressing Scheme, Its
Implications, and Considerations for Implementation",
NTIA Report 85-186, (available from NTIA, Boulder CO)
[RFC85] Mills, David, "Internet Delay Experiments," RFC889,
December 1983 (available from the Network Information
Center).
[SPI82] Spirn, Jeffery R., "Network Modeling with Bursty
Traffic and Finite Buffer Space," Performance
Evaluation Review, vol. 2, no. 1, April 1982.
[SPI84] Spirn, Jeffery R., Jade Chien, William Hawe,
"Bursty Traffic Local Area Network Modeling,"
IEEE Journal on Selected Areas in Communications,
vol. SAC-2, no. 1, January 1984.