RFC relevance of connection

As per Relevance of the word connection, we have this rfc below:

Network Working Group Rajendra K.
Request for Comments #663 MIT, Project
NIC #31387 November 29, 1974

A LOST MESSAGE DETECTION AND RECOVERY

1.0

The current Host-to-Host protocol does not provide for
following three aspects of network communication

1. detection of messages lost in the transmission
2. detection of errors in the
3. procedures for recovery in the event of lost messages
data errors

In this memo we propose an extension to the Host-to-Host
that will allow detection of lost messages and an
recovery from this situation. If Host-to-Host protocol were
be amended to allow for detection of errors in the data, it
expected that the recovery procedures proposed here will apply

With the present protocol, it may some times be possible
detect loss of messages in the transmission path. However,
a lost message (especially one on a control link) simply
in an inconsistent state of a network connection. One
(and frustrating) symptom of a message loss on a control link
been the "lost allocate" problem which results in a "paralyzed
connection. The NCP (Network Control Program) at the
site believes that sender has sufficient allocation for
connection, whereas the NCP of the sending host believes that
has no allocation (due to either loss of or error in a
that contained the allocate command). The result is that
sending site can not transmit any more messages over
connection. This problem was reported in the NWG-RFC #467
Burchfiel and Tomlinson. They also proposed an extension to
Host-to-Host protocol which allows for resynchronization of
connection status. Their proposed solution was opposed by
Meyer (NWG-RFC #492) and Wayne Hathaway (NWG-RFC #512) on
grounds that it tended to mask the basic problem of loss
messages and they suggested that the fundamental problem
message loss should be solved rather than its symptoms. As
alternative to the solution proposed in NWG-RFC #467,
Hathaway suggested that Host-to-Host protocol header could
extended to include a "Sequence Control Byte" to allow
of lost messages. At about the same time Jon Postel suggested
similar scheme using message numbers (NWG-RFC #516). A
later David Walden proposed that four unused bits of the
sequence number (in the IMP leader) be utilized for

- 1 -

messages (NWG-RFC #534). His scheme is similar to those
by Postel and Hathaway; however it has the advantage
Host-to-Host protocol mechanisms can be tied into the IMP-to-
protocol mechanisms

The protocol extension proposed here uses the four bits of
message sequence number in the message leader for detection
lost messages. However, to facilitate recovery, it uses
eight bit field (presently unused) in the 72 bit header of
regular messages. In the next section of this paper we
some of the basic ideas underlying our protocol. In section 3,
we provide a description of the protocol. It is our
that section 3 be a self-contained and complete description
the protocol

2.0 BASIC

The purpose of this section is to provide a gentle
to the central ideas on which this protocol is based.
speaking, our protocol can be divided into three
components. First is the mechanism for detecting loss
messages. Second is the exchange of information between
sender and the receiver in the event of a message loss.
reasons that will soon become obvious, we have termed this
as "Exchange of Control Messages". The third component of
protocol is the method of retransmission of lost messages.
this section, we have reversed the order of discussion for
second and third components, because the mechanisms for
of control messages depend heavily upon the
methods

A careful reader will find that several minor issues have
left unresolved in this section. He (or she) should
that this section is not intended to be a complete description
the protocol. Hopefully, we have resolved most of these
in the formal description of the protocol provided in the
3.

2.1 DETECTION OF LOSS OF

The 32 bit Host-to-IMP and IMP-to-Host leaders contain a 12
message-id in bit positions 17 to 28 (BBN Report #1822).
Host-to-Host protocol (NIC 8246) uses 8 bits of the message-
(bit positions 17 to 24) as a link number. The remaining 4
of the message-id (bits 25 to 28) are presently unused. For
purposes of the protocol to be presented here, we define

- 2 -

four bits to be the message sequence number (MSN in short
associated with the link. Thus message-id consists of an
bit link number and a four bit message sequence number. The
bit MSN provides a sixteen element sequence number for each link
A network connection has a sending host (referred to as "sender
henceforth), a receiving host (referred to as
henceforth), and a link on which messages are transmitted.
our protocol the sender starts communication with the value
MSN set to one (i.e. the first message on any link has one in
MSN field.) For the next message on the same link the value
MSN is increased by one. When the value of MSN becomes 15
next value chosen is one. This results in the following
1, 2, ...., 13, 14, 15, 1, 2, ...., etc. The receiver can
loss of messages by examining this sequence. Each
corresponds to a lost message. Notice that the
mechanism will fail if a sequence of exactly 15 messages were
be lost. For the time being, we shall assume that
probability of loosing a sequence of exactly 15 messages
negligible. However, we shall later provide a status
mechanism (Section 2.6) that can be used to prevent this failure

Notice that in the sequence described above we have omitted
value zero. Following a suggestion made by Hathaway (NWG-
#512) and Walden (NWG-RFC #534) the new protocol uses the
zero to indicate to the receiving host that the sending host
not using message sequence numbers. We, in fact, extend
meaning associated with the MSN value zero to imply that
sending host has not implemented the detection and error
protocol being proposed here

2.2

The discussion above brings us to the issue of
between the present and the new protocols. Let us define
hosts with the present protocol to be type A and the hosts
the new protocol to be type B. We have three situations

1. Type A communicating with type A: there is
difference from the present situation
2. Type A communicating with type B: from the zero
MSNs in messages sent by the type A host, the type
host can detect the fact that the other host is a type
host. Therefore the type B host can simulate
behaviour of a type A host in its communication with
other host, and the type A host will not be confused
As we will see later that this simulation is
simple and can be easily applied selectively
3. Type B host communicating with type B: Both hosts
detect the fact that the other host is a type B host

- 3 -

use the message detection and error recovery protocol

There is one difficulty here that we have not yet resolved.
starting communication how does a type B host know whether
other host is type A or type B? This difficulty can be
by assuming that a type A host will not be confused by a non-
MSN in the messages that it receives. This assumption is
unreasonable because a type A host can easily meet
requirement by making a very simple change to its NCP (
Network Control Program), if it does not already satisfy
requirement. Another assumption that is crucial to our protocol
is that the type A hosts always set the MSN field of
(they send out) to zero. As of this writing, the author
that no hosts are using the MSN field and therefore
compatibility problem should arise

2.3 RETRANSMISSION OF

Before getting down to the details of the actual protocol,
will attempt here to explain the essential ideas underlying
protocol by considering a somewhat simplified situation
Consider a logical communication channel X, which has at
disposal an inexhaustible supply of physical
channels C(1), C(2), C(3), ........, etc. (See footnote #1)
Channel X is to be used for transmission of messages.
addition to carrying the data, these messages contain (1)
channel name X, and (2) a Message Sequence Number (MSN). Let
denote the sender on this channel by S and the receiver by R
Let us also assume that at the start of the communication, R
S are synchronized such that R is prepared to receive
for logical channel X on the physical channel C(1) and S
prepared for sending these messages on C(1). S starts by
a sequence of messages M(1), M(2), M(3), ........, M(n)
channel C(1). Since these messages contain sequence numbers,
is able to detect loss of messages on the channel C(1).
now that R discovers that message number K (where K in the transmission path. Let us further assume that
_________________________________________________________________

(1) One method of recovery may be to let the receiver save
properly received messages and require the sender to
only those messages that were lost. This method requires
receiver to have the ability to reassemble the messages to
the data stream. A second method of recovery may be to abort
restart the transmission at the error point. This
requires that the receiving host be able to distinguish
legitimate messages and messages to be ignored. For
we have chosen the second method and an inexhaustible supply
physical channels serves to provide the distinction
messages

- 4 -

discovered loss of a message, R can communicate this fact to S
sending an appropriate control message on another logical
that is explicitly reserved for transmission of control
from R to S. This channel, named Y, is assumed to be
reliable

We now provide a rather simplistic recovery protocol for
scenario sketched above. Having detected the loss of message M(K
on channel X, R takes the following series of actions

1- R stops reading messages on C(1),
2- R discards those messages that were received on C1
are placed after M(K) in the logical message sequence
3- R prepares itself to read messages M(K), M(K+1), .....,
etc. on the physical channel C(2),
and 4- R sends a control message to S on control channel Y
which will inform S to the effect that there was
error on logical channel X while using physical
C(1) in message number K

When S receives this control message on Y, it takes the
action

1- S stops sending messages on C(1),
and 2- begins transmission of messages starting with
sequence number K, on the physical channel C(2).

This resynchronization protocol is executed every time R
an error. If physical channel C(CN) was being used at the
of the error, then the next channel to be used is C(CN+1).
can define a "receiver synchronization state" for the channel X
as the triplet R(C, CN, MSN), where C is the name of the group
physical channels, CN is the number of the physical channel
use, and MSN is the number of message expected. (See footnote #1)
We can specify a message received on a given C-channel as M(MSN).
When R receives the message M(R.MSN) on the channel C(R.CN),
synch-state changes from R(C, CN, MSN) to R(C, CN, MSN+1).
However if M.MSN for the message received is greater than R.
then a message has been lost, and R changes the synch-state
R(C, CN+1, MSN). What really happens may be described
follows: upon detection of error in a logical channel X,
merely discard the physical channel that was in use at the
of error, and restart communication on a new physical channel
the point where break occurred
_________________________________________________________________

(1) Notice that we have prefixed this triplet by the letter
(for the receiver.) We will prefix other similarly
quantities by different letters. For example M can be used
messages. This notation permits us to write expressions
M.MSN = R.MSN, where M.MSN stands for the message sequence
of the message

- 5 -

This scheme provides a reliable transmission path X, even
the physical channels involved are unreliable. In this scheme
have assumed that (1) a completely reliable channel Y
available for exchange of control messages, and (2) that there
a large supply of physical channels available for use of X.
the paragraphs that follow we shall revise our protocol to use
single physical channel and then apply this protocol to
channel Y in such a way that Y would become "self-correcting."

Now suppose that channel X has only one physical channel (
X') available for its use rather than the inexhaustible supply
physical channels. Our protocol would still work, if we
somehow simulate the effect of a large number of C-channels
the single channel X'. One method of providing this
is to include in each message the name of the C-channel on
it is being sent, and send it on X'. Now the receiver
examine each message received on X' to determine the C-channel
which this message was sent. Our protocol still works except
one minor difference, namely, the receiver must now
messages corresponding to C-channels that are no longer in use
whereas in the previous system the C-channels no longer
used were simply discarded. To be sure, X' can be
among only a finite number of C-channels; however, we can
a sufficiently large number of C-channels so that during the
time of the logical channel X, the probability of exhausting
supply of C-channels would be very low. And even if we were
exhaust the supply of C-channels, we could recycle them just
we recycle the message sequence numbers

A physical message received on X' can now be characterized by
pair of C-channel number and a message sequence number, as M(CN
MSN). The receiver synchronization state becomes a triplet R(X',
CN, MSN). This state tells us that R is ready to receive
message for X on the physical channel X' and for this
M.CN should be equal to R.CN and M.MSN should be equal to R.MSN
All messages with M.CN less than R.CN will be ignored. If
the next message received on X', M.CN = R.CN and M.MSN = R.MSN
then R changes the synch state to R(X', CN, MSN+1). If M.CN =
R.CN but M.MSN > R.MSN then a message has been lost and
synch-state R(X', CN, MSN) changes to R(X', CN+1, MSN).
that we have not yet said anything about the situation M.CN >
R.CN. We will later describe a scheme for using this case
provide for error correction on the control channel itself

2.4 EXCHANGE OF CONTROL

So far we have discussed two schemes for the detection
retransmission aspects of the lost-message problem. In

- 6 -

section, we discuss methods by which the receiver communicates
the sender the fact of loss of messages

We continue with the scenario developed in the above section
a small change. For the purposes of the discussion that is
to follow we shall assume that there are actually two
channels available for exchange of control messages. One
from S to R named S->R, and the other from R to S named R->S
The purpose of S->R will become clear in a moment. In order
let R communicate the fact of loss of messages to S, We provide
control message called L__o_s_t__M_e_s_s_a_g_e__f_r_o_m__R_e_c_e_i_v_e_r (LMR) which
of the following form: LMR(X, CN, MSN), where X is the name
the channel, CN is the new C-channel number, and MSN is
message sequence number of the lost message. If more than
message has been lost, then R uses the MSN of the first
only. When S receives this message, it can restart
at the point where the break occurred using the C-
specified by the LMR message. This will restore
communication path X. What happens if S can not
communication at the break point because it does not have
relevant messages any more? This issue can be solved in one
the two ways: either let the protocol specify a fixed rule that
will be required to close the connection, or the protocol
allow S and R (and may be the users on whose behalf S and R
communicating on X) to negotiate the action to be taken. For
protocol to be presented here, we have taken the approach that
may, at its option, either close the connection or negotiate
R. What action a specific host takes can either be built
its NCP or determined dynamically. Those hosts that do not
very powerful machines will probably chose the static option
closing the connection; other hosts may make the
depending upon the circumstances. For example, a host may
that loss of messages is not acceptable during file
whereas loss of a single message can be ignored for
output to interactive users. A host might even let the
processes decide the course of action to be taken. If
determines that it can not retransmit lost messages, it may
to let R decide what action is to be taken. If S so decides
then it may communicate this fact to R by transmitting
_L_o_s_t__M_e_s_s_a_g_e__f_r_o_m__S_e_n_d_e_r (LMS) control message to R on
channel S->R. An LMS message is of the following form: LMS(X
CN, MSN, COUNT), where X is the name of the channel, CN is
name of the C-channel obtained from the LMR message, MSN is
message sequence number of the first message in the sequence
lost messages, and COUNT is the number of messages in
sequence. S resets its own synch-state for connection X to S(X
CN, MSN+COUNT). When S has informed R of its inability
retransmit lost messages, the burden of the decision falls on R
and S simply awaits R's reply before taking any action for
channel X. When R receives the LMS, it may either decide
loss is unacceptable and close the connection, or it may
to let S continue. In the later case R informs S of its

- 7 -

to continue by transmitting a L__o_s_s__o_f__M_e_s_s_a_g_e__A_c_c_e_p_t_a_b_l_e (LMA
control message to S. Upon receiving the LMA control message,
resumes transmission on X. To avoid the possibility of errors
exchange of control messages, the LMA control message
specified to be an exact replica of the LMS control message
except for the message code which determines whether a
message is LMA or LMS or something else

In general, a sending host has only a limited amount of
available for storing messages for possible retransmission later
In section 2.6 we provide a status exchange mechanism that can
used to determine when to discard these messages

2.5 RECOVERY ON CONTROL

We continue our discussion with the scenario developed in
previous section. The receiver R may detect loss of messages
control channels by examining the message sequence numbers on
messages. When R detects that a message has been lost on
channel S->R, it (R) may transmit an LMR to S on R->
communicating the fact of loss of messages. When S receives
LMR for the control link, it must either retransmit the
messages, or "close" the connection. (In the context
Host-to-Host protocol, closing the network connection for
link implies exchange of reset commands, which has the effect
reinitializing all communication between R and S.) For
links, S does not have the option of sending an LMS to
receiver. If S can not retransmit the lost messages then
aborts the output queue (if any) for the channel S->R,
inserts a Reset command at the break point. Essentially, we
specifying that if S can not retransmit lost control
then the error would be considered irrecoverable and fatal.
user communication between S and R is broken and must
restarted from the beginning

In the above paragraph, we considered the situation in which
was able to detect the loss of messages. It is however
that it is the last message transmitted on S->R that is lost.
this case, R will not be aware of the loss. In this situation
recovery can be initiated only if S can either
determine or simply suspect that a message has been lost.
general, after having transmitted a control message, S would
expecting some sort of response from R. For example, if
transmits a Request-for-Connection (RFC) control message to R,
expects R to reply either with a Close (CLS) command or
RFC. If, after an appropriate time interval has elapsed and
has received no reply from R, our protocol specifies that S
retransmit the control message. In retransmitting, S must

- 8 -

the same C-channel and MSN values that were used for the
message. Since R can, now, receive duplicate copies,
stipulate that if R receives a duplicate of the message that
has already received, it may simply ignore the duplicate

2.6 SOME OTHER

There are two problems that have not yet been solved. First,
sending host will usually have only a limited amount of
space in which it can save messages for possible
retransmission. So far, we have not provided any method by
a host may positively determine whether the receiver
correctly received a certain message or not. Thus it has no
basis on which it may decide to release the space used up
messages that have been already transmitted. The second
is created by our recycling the message sequence numbers.
the MSN mechanism to work correctly, it is essential that at
given instant of time there be no more than 15 messages in
transmission path. If there were more than 15 messages, some
these messages would have same MSN and LRN, and if one of
messages were to be lost, it would be impossible to identify
lost message. However, the second problem should not arise
the ARPA Network, since the IMP sub-network will not allow
than eight outstanding messages between any host pair (NWG-
#660).

We can solve both these problems by a simple yet highly
scheme. In this scheme, there are two new control messages.
of these, called R__e_q_u_e_s_t S__t_a_t_u_s _f_r_o_m S__e_n_d_e_r (RSS), can be used
the sending host to query the receiver regarding the receiver'
synch-state. The receiver can supply its copies of C-
number and MSN for a transmission path by sending a S__t_a_t_u_s _f_r_o_
R__e_c_e_i_v_e_r (SFR) control message over the control channel. An
provides positive acknowledgement; differing with the
acknowledgement schemes in only that here acknowledgement
provided only upon demand. Upon receiving SFR, the sender
exactly which messages have been properly delivered, and it
free the buffer space used by these messages. The RSS and
scheme can also be used to ensure that there are no more
fifteen messages in the transmission path at any given time

- 9 -

3.0 LOST MESSAGE DETECTION AND RECOVERY

This protocol is proposed as an amendment to the Host-to-
Protocol for the purpose of letting hosts detect the loss
messages in the network. It also provides recovery
from such losses. This protocol is divided into two parts.
1 states the compatibility requirements. Part 2 states the
protocol and must be implemented by hosts that desire to have
ability to recover from loss of messages in the network.
reader will find many comments interspersed throughout
description of this protocol. These comments are not part of
protocol and are provided solely for the purpose of improving
reader's understanding of this protocol

The terminology used in this protocol is similar to that used
the Host-to-Host protocol. We speak of a "network connection
between a pair of hosts, called the "receiver" and the "sender."
A network connection is described by a pair of socket numbers
and once established, a network connection is associated with
link (which is described by a link number.) A network
is a logical communication path and the link assigned to it is
physical communication path. In addition to links
with the network connections, there are "control-links" for
transmission of "control commands." When we use the
"connection" it may refer to either a network connection or
link assigned to it; the context decides which one. The
"links" encompasses the connection-associated-links as well
control-links. Notice that a receiver of a connection
transmit control commands regarding this connection

3.1

3.1.1 HOST TYPE "A

Those hosts that have not adopted the part 2 of this
amendment will be known as type A hosts

(Comment: All existing hosts are type A hosts.)

3.1.2 HOST TYPE "B

Those hosts, that adopt the part 2 of this protocol
will be known as type B hosts

- 10 -

3.1.3 MESSAGE SEQUENCE NUMBER (MSN

A four bit number associated with regular messages and
in the bits 25 through 28 of the Host-to-IMP and IMP-to-
leaders for regular messages [BBN Report No. 1822]. This
is used by the type B hosts to detect loss of messages on
given link. Type A hosts always set the MSN (for the
they send out) to zero. When in use by a type B host, the
message on a link (after the connection has been established)
the MSN value of one. For each successive message on this link
the MSN value is increased by one until it reaches a value of 15.
The next message has the MSN value of one

(Comments: Type B hosts will use the MSN mechanism only
communicating with other type B hosts. If a type B host
communicating with a type A host, the type B host
essentially simulate the behaviour of a type A host and use
MSN values for this communication.)

3.1.4 LINK RESYNCH NUMBER (LRN

The Link Resynch Number is an eight bit number associated with
link and used for resynchronizing the communication. For
associated with a network connection (i.e. user links), it
intially set to zero. For control links, it is set to zero
the time of the Network Control Program (NCP) initialization
For a given link, its current LRN value is copied into the
field of all messages sent out on the link. The LRN values
be manipulated by type B hosts in accordance with the
described later

(Comments: Our protocol specifies that for all
involving a type A host, the LRN value will never change
zero. Since the LRN field is presently unused, all hosts set
to zero even though they do not explicitly recognize this
as an LRN field. This guarantees compatibility.)

3.1.5 LRN

An eight bit field in the bits 33 through 40 of the Host-to-
message header

- 11 -

3.2 NEW CONTROL

3.2.1 LMR - LOST MESSAGE FROM

___8______8_______8_______8____
| I I I
I LMR | link | LRN | MSN
I______I_______I_______I______I_

The LMR command is sent by a receiving host to let the
host know that one or more messages have been lost. The
field specifies the message sequence number of the first
lost. The LRN field specifies the new LRN value that must
used if and when communication is restored

(Comments: As will be seen later, the LMR command also has
effect of resetting the bit and message allocation in the
host to zero. In order to permit a sender to
communication, an LMR command will be usually accompanied with
allocate command. However notice that these comments do
apply to the control links because there is no
mechanism for the control links.)

3.2.2 LMS - LOST MESSAGE FROM

____8_________8________8__________8_________8_____
I I I I I
I LMS I Link I LRN I MSN I COUNT
I__________I________I_________I__________I________I_

This command is sent by a sender host in reply to an LMR
if it (the sender) can not retransmit the lost messages
by the LMR command. The purpose of this command is to query
receiver whether or not the loss of messages is acceptable
After sending this command, the sender waits for a reply
transmitting any messages over the link involved. This
may not be sent for control links. The LRN and MSN values
same as those specified by the LMR command. COUNT specifies
number of messages lost

3.2.3 LMA - LOSS OF MESSAGES

This command is identical to the LMS command accept for
command code. Upon receipt of an LMS command, a receiver

- 12 -

send this command to the sender to let the sender know that
of messages is acceptable. All fields in this command are set
corresponding values in the LMS command

3.2.4 CLS2 - CLOSE

____8___________3_2_______________3_2_____________8_______8______
I I I I I
I CLS2 I my socket I your socket I LRN I MSN
I________I_______________I__________________I________I_______I_

The CLS2 command is similar to the current CLS command except
the LRN and MSN fields included in the new command. Both
receiving and sending hosts copy their values of LRN and MSN
the CLS2 command. Upon receiving a CLS2 command, a host
the LRN and MSN values contained in the CLS2 command with its
values for the connection involved. If these values do
match, then an error has occurred and a host may
recovery procedures

(Comments: The purpose of this command is to ensure that
last message transmitted on a connection has been
succesfully.)

3.2.5 ECLS - ERROR

_____8___________3_2___________3_2_________
I I I
I ECLS I my socket I your
I_________I______________I______________I_

The ECLS command is similar to the current CLS command. It
used for closing connections which have sufferred
irrecoverable loss of messages

(Comments: A connection may be closed in any one of the
three ways

1. A connection which has not yet been opened
may be closed by the CLS command. All
involving type A hosts must be closed using the
command
2. Connections between type B hosts may be closed
CLS2 command. A connection is considered closed
if matching CLS2 commands have been exchanged

- 13 -

the sender and the receiver
3. Those connections between type B hosts, that
sufferred an irrecoverable loss of messages, must
closed by the ECLS command.)

3.2.6 RSS - REQUEST STATUS FROM

____8_______8______
I I
I RSS I LINK
I_______I_________I_

A sending host may issue an RSS command to find out about
status of transmission on a particular connection or the
link

3.2.7 RSR - REQUEST STATUS FROM

____8_________8_____
I I
I RSR I LINK |
I________I_________I_

A receiver can issue an RSR command to find out about the
of transmission on a particular connection or the control link

3.2.8 SFR - STATUS FROM

____8_________8_________8_________8____
I I I I
I SFR I LINK I LRN I MSN
I_________I_________I_________I________I_

A receiving host may issue this command to inform the
about the state of a particular connection or the control link

3.2.9 SFS - STATUS FROM

- 14 -

____8_________8_________8_________8____
I I I I
I SFS I LINK I LRN I MSN
I_________I_________I_________I________I_

A sending host may issue this command to inform the
about the state of a particular connection or the control link

3.3 THE

3.3.1 PART

All type A hosts must use zero MSN and LRN values on the
sent out by them. When communicating with a host of type A,
type B host must simulate the behaviour of type A host

(Comments: Notice that this simulation is not complicated
all. All that is required is that hosts that adopt
protocol must not use it when communicating with the hosts
have not adopted it.)

3.3.2 PART

This part of the protocol is stated as a set of rules which
be observed by all type B hosts when communicating with
type B hosts

3.3.2.1 RESPONSIBILITIES OF HOSTS AS

(1). A type B sending host must use message sequence
on all regular messages that it sends to other type
hosts as specified in the definition of the
sequence numbers (Section 3.1.3).
(2). A type B sending host must use link resynch numbers
all regular messages that it sends to other type
hosts as specified in the definition of link
number (Section 3.1.4).
(3). A sending host may retransmit a message if it
that the message may have been lost in the
during previous transmission
(4). A sending host may issue an RSS command to the
to determine the state of transmission on any link
(5). A sending host must use the ECLS command to close
connection, if the connection is being closed due to

- 15 -

irrecoverable transmission error. Otherwise, it
the CLS2 command

3.3.2.2 RESPONSIBILITIES OF HOSTS AS

(1). A receiver host will maintain LRN and MSN values
each link on which it receives messages. Initial
of LRN will be zero, and initial value of MSN will
one. For each receive link, the host should
prepared to receive a message with LRN and MSN
specified by its tables. When the host has
the expected message on a given link, it will
its table MSN value as specified in the definition
MSN
(2). On a given link, if a host receives a message with
LRN value smaller than the one in use, it will
the message
(3). If a host receives a duplicate message (same LRN
MSN values), it will ignore the duplicate
(4). A host will examine the MSN values on all
messages that it receives to detect loss of messages
If on any link, one or more messages are found missing
it will concern itself with only the first message
and take the following series of action

1. Increase its own LRN value for this link
one
2. Send an LMR command to the sending host
LRN field set to the new value and MSN
set to the sequence number of the
message lost
3. Realizing that LMR command will cause
allocation to be reset to zero, it will
more allocation. This is not applicable
the control links

However, if a host does not want to initiate
recovery procedures, it may simply close the
by an ECLS command
(5). A receiver host may issue the RSR command to
the state of transmission on any link
(6). If a connection is being closed due to an
error, a receiving host must use the ECLS command
Otherwise it must use the CLS2 command

- 16 -

3.3.2.3 SENDING HOST'S RESPONSE TO CONTROL

(1). RSR command: the sender must transmit a SFS command
the receiver for the link involved
(2). ECLS command: The sender must cease transmission, if
has not already done so, and issue an ECLS command
it has not already issues either a ECLS or CLS
command
(3) CLS2 command: The sender must compare the LRN and
values of the CLS2 command with its own values of
LRN and MSN for the connection involved. If an
is indicated, it may either close the connection
an ECLS, or initiate recovery action as specified
the section 3.3.2.1.
(4). LMR command for a connection (i.e., not a
link): The sender may follow any one of the
three courses of action

1. Close the connection with an ECLS command
2. Set the allocations for the link involved
zero, set LRN to that specified in the
command, and restart communication at
point of break
3. Set the allocations for the link involved
zero, set the LRN to that specified in
LMR command, and send an LMS command to
receiver host informing him that one or
of the lost messages can not
retransmitted. After sending an LMS command
a sending host must not transmit any
messages on the link involved until
unless it receives an LMA command from
receiver host

(Comments: As we have mentioned before (Section 2.3),
decision regarding which course of action to follow depends
a number of factors. For example, if a host has implemented
the detection of lost messages aspect of our protocol (and
recovery), then it will chose the first option of closing
connection.)

(5). LMR for a control link: The sender may take one of
following two actions

1. Set the LRN to that specified in the
command and begin retransmission of

2. Set the LRN to that specified by the
command, and insert a Reset command at
break point

- 17 -

(Comment: If a sending host can not retransmit messages lost
a control link, then this protocol requires that
communication between the two host be broken, and reinitialized
We do not explicitly specify the actions that are associated
the exchange of Reset commands. These actions are specified
the Host-to-Host protocol.)

(6). LMA command: When a sending host receives an
command matching an LMS command previously issued
it, it may resume transmission

(Comments: The protocol does not require the sending host to
any specific action with regard to a SFR. However, a sending
may use the information contained in the SFR command
the state of transmission. From a SFR command a sender host
determine what messages have been received properly. The
may use this information to cleanup its buffer space
retransmit messages that it might suspect are lost.)

3.3.2.4 RECEIVING HOST'S RESPONSE TO CONTROL

(1). RSS command: A receiver is obligated to transmit a
to the sender for the link involved

(2). ECLS command: The receiver must close the
by issuing an ECLS command if it has not already
so

(3). CLS2 command: A receiver must compare the LRN and
values of the command with its own values for
connection involved. If an error is indicated, it
either close the connection by an ECLS command
initiate recovery procedures as specified in
3.3.2.2.

(4). LMS command: The receiver may take one of the
two courses of action

(1). Close the connection specified by the
command, by issuing an ECLS command
(2). Set the link involved to be prepared
receive messages starting with the
number MSN + COUNT, where MSN and COUNT
those specified by the LMS command
(Comment: This action implies that
is willing to accept the loss of
specified by the LMS command.)

(Comments: The protocol does not require the receiver to take
specific action with regard to a SFS command. However a

- 18 -

host may use the information contained in it.)

4.0 CONCLUDING

The design of this protocol has been governed by three
principles. First, we believe that to be useful within the
Network, any new protocol must be compatible with the
protocols, so that each host can make the transition to the
protocol at its own pace and without large investment. Secondly
the protocol should tie into the recovery mechanism of
IMP-to-Host Protocol. The price we pay for this is the small
field and a message oriented protocol rather than a byte
oriented protocol. The third consideration has been flexibility
While this protocol guarantees detection of lost messages,
philosophy behind the recovery procedures is that a host
have several options, each option providing a different degree
sophistication. A host can implement a recovery procedure
is most suitable for its needs and the capabilities of
machine. Even though two hosts may have implemented
recovery procedures, they can communicate with each other in
compatible way. In a network of independent machines of
varying capabilities and requirements, this seems to be the
way of implementing such a protocol. Even though this
provides a variety of options in a given error situation,
choice of a specific action must be consistent with the
requirements of the communication path. For example,
recovery is not acceptable during file transfers. We
expect the File Transfer Protocol to specify that if
irrecoverable error occurs, the file transfer must be aborted

- 19 -

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX