RFC 663

Lost message detection and recovery protocol

📅 published November 1974, from ietf

RFC 663: A Lost Message Detection and Recovery Protocol ✨

bestie, this one is from the Network Working Group 🌸 It's RFC #663 (also NIC #31387), and it's titled A Lost Message Detection and Recovery Protocol. Rajendra K. Kanodia wrote it at MIT, Project MAC, and it's dated November 29, 1974 📅 The header doesn't list a category, and it doesn't say what it obsoletes or updates, so we just don't know those details from the top. 🤷‍♀️

1.0 Introduction 🎀

okay so the current Host-to-Host protocol doesn't handle three things 😭

  1. detecting messages that get lost on the way
  2. detecting errors in the data
  3. having procedures to recover when messages get lost or the data is wrong

In this memo, Kanodia proposes an extension to Host-to-Host that lets you detect lost messages and recover from them in an orderly way 🫶 The author also says that if Host-to-Host ever gets amended to detect data errors, the recovery procedures proposed here are expected to apply to that too 💅

Now, the current protocol can sometimes notice that a message went missing in the transmission path 👀 But honestly? A lost message (especially one on a control link) usually just leaves a network connection in an inconsistent state 💀 A super frustrating example is the "lost allocate" problem, which leaves a connection "paralyzed" 😩 Here's how it goes: the NCP (Network Control Program) at the receiving site thinks the sender has enough allocation for a connection, but the NCP at the sending host thinks it has no allocation. That happens because a message containing the allocate command was either lost or had an error in it. The result? The sending site can't send any more messages over the connection. Iconic behavior, not in a good way 🙃

This problem was reported in NWG-RFC #467 by Burchfiel and Tomlinson, who also proposed an extension to Host-to-Host that lets the connection status resynchronize 🔄 But Edwin Meyer (NWG-RFC #492) and Wayne Hathaway (NWG-RFC #512) pushed back on that fix. Their reason was that it kind of hides the real problem, which is message loss, so they said the fundamental problem should be solved instead of the symptoms 🧠

As an alternative to the #467 solution, Hathaway suggested extending the Host-to-Host header with a "Sequence Control Byte" so lost messages can be detected 🔍 Around the same time, Jon Postel proposed something similar using message numbers (NWG-RFC #516) ✨ A bit later, David Walden proposed using four unused bits of the message sequence number (in the IMP leader) for sequencing messages (NWG-RFC #534) 💜 His idea is similar to Postel's and Hathaway's, but it has an extra perk: Host-to-Host mechanisms can be tied into the IMP-to-Host mechanisms 🦋

The protocol extension in this memo uses the four bits of the message sequence number in the message leader to detect lost messages. For recovery, though, it also uses another eight bit field (currently unused) in the 72 bit header of the regular messages 🌈 Section 2 covers the basic ideas, and Section 3 has the protocol description. Kanodia says Section 3 is meant to be a self-contained and complete description of the protocol 🫶

2.0 Basic Ideas 🧚

This section is a gentle intro to the main ideas behind the protocol. Roughly speaking, the protocol has three big parts 🔥 First is the mechanism for detecting lost messages. Second is the exchange of information between the sender and the receiver when a message is lost. The author calls that second part "Exchange of Control Messages" (it's giving very clear naming, periodt 💅). The third part is how lost messages get retransmitted. This section discusses the second and third parts in reverse order, because the control message exchange depends heavily on the retransmission methods 🔄

Be warned, bestie: this section leaves several minor issues unresolved 🙈 A careful reader will notice, and they should keep in mind that this section isn't meant to be a complete description of the protocol. The author hopes most of these issues get resolved in the formal description in Section 3 ✨

2.1 Detection of Loss of Messages 🔍

Okay, this part is the core of the detection trick 🤓 The 32 bit Host-to-IMP and IMP-to-Host leaders contain a 12 bit message-id in bit positions 17 to 28 (BBN Report #1822). The Host-to-Host protocol (NIC 8246) uses 8 bits of the message-id (bit positions 17 to 24) as a link number. The remaining 4 bits of the message-id (bits 25 to 28) are currently unused. For this protocol, those four bits are defined as the message sequence number (MSN for short) tied to the link. So the message-id is made of an 8 bit link number plus a 4 bit MSN 💖 The 4 bit MSN gives you a sixteen element sequence number for each link ✨

Here's the setup: a network connection has a sending host (called the "sender"), a receiving host (called the "receiver"), and a link that messages go over 🛤️ In this protocol, the sender starts communication with MSN set to one, so the first message on any link has one in its MSN field. For each next message on the same link, the MSN goes up by one. When the MSN hits 15, the next value is one. That gives you this sequence:

1, 2, ...., 13, 14, 15, 1, 2, ...., etc.

The receiver can spot lost messages by looking at this sequence. Each hole = one lost message 🕳️ Heads up though: the detection mechanism will fail if exactly 15 messages in a row get lost 😬 For now, the author assumes that losing exactly 15 messages in a row is negligible (it's giving "not gonna happen"). Later, though, there's a status exchange mechanism (Section 2.6) that can prevent this failure 🛡️

Notice that the value zero got left out of that sequence on purpose 👀 Following suggestions from Hathaway (NWG-RFC #512) and Walden (NWG-RFC #534), the new protocol uses the value zero to tell the receiving host that the sending host is not using message sequence numbers. The author goes further and says the meaning of MSN value zero also implies that the sending host hasn't implemented the detection and error recovery protocol proposed here 💀

2.2 Compatibility 🫶

Now for the compatibility question, which is a big deal 🌸 The author defines hosts that use the present protocol as type A, and hosts that use the new protocol as type B. There are three situations:

  1. Type A communicating with type A: there's no difference from the present situation.
  2. Type A communicating with type B: the type B host can tell from the zero value MSNs in messages sent by the type A host that the other host is type A. So the type B host can simulate the behaviour of a type A host in its communication with the other host, and the type A host won't get confused. The author says this simulation is really simple and can easily be applied selectively 💅
  3. Type B host communicating with type B: both hosts can tell the other is type B, and they use the message detection and error recovery protocol 🎉

There's one difficulty the author hasn't figured out yet 😤 When communication starts, how does a type B host know whether the other host is type A or type B? The author's answer is to assume that a type A host won't be confused by a non-zero MSN in messages it receives. The author thinks that's not unreasonable, because a type A host can meet this requirement with a very simple change to its NCP (the Network Control Program), if it doesn't already do it 🛠️ The protocol also depends on another assumption: type A hosts always set the MSN field of the messages they send to zero 🙌 As of when this was written, the author believes no hosts are using the MSN field, so no compatibility problem should come up 🌈

2.3 Retransmission of Messages 🔁

Before getting into the real protocol details, the author explains the core ideas using a somewhat simplified situation 🧸 Picture a logical communication channel X with an inexhaustible supply of physical communication channels C(1), C(2), C(3), ........, etc. (see footnote #1). Channel X carries messages. Besides the data, each message contains (1) the channel name X, and (2) a Message Sequence Number (MSN). The sender on this channel is S, and the receiver is R 📦

At the start, R and S are synchronized, so R is ready to receive messages for logical channel X on physical channel C(1), and S is ready to send them on C(1) ✅ S starts by pumping a sequence of messages M(1), M(2), M(3), ........, M(n) into channel C(1). Since the messages have sequence numbers, R can detect lost messages on channel C(1) 🕵️‍♀️ Now say R notices that message number K (where K < n) got lost in the transmission path. The author also assumes that once R has discovered the loss, R can tell S about it by sending a control message on a different logical channel that's reserved just for control messages from R to S. That channel is called Y, and it's assumed to be completely reliable 💜

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

Here's the simplistic recovery protocol for that scenario 🔥 After R detects the loss of message M(K) on channel X, R does the following, in order:

  1. R stops reading messages on C(1).
  2. R discards those messages that were received on C1 and 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).
  4. R sends a control message to S on control channel Y, which will inform S about the fact that there was an error on logical channel X while using physical channel C(1) in message number K.

When S gets this control message on Y, it takes the following

action:

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

okay so this resynchronization protocol runs every single time R detects an error 😭 If physical channel C(CN) was being used at the time of the error, then the next channel to be used is C(CN+1) 🦋 We 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 of physical channels, CN is the number of the physical channel in 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), the 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.MSN, then a message has been lost, and R changes the synch-state to R(C, CN+1, MSN). 💅 What really happens is this: upon detection of an error in a logical channel X, we just discard the physical channel that was in use at the time of the error, and restart communication on a new physical channel at the point where the break occurred. iconic 🎀

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

This scheme gives us a reliable transmission path X, even though the physical channels involved are unreliable 🌸 Two things we're assuming here: (1) a completely reliable channel Y is available for exchange of control messages, and (2) there is a large supply of physical channels available for use of X. In the paragraphs that follow, we'll revise our protocol to use a single physical channel, and then apply this protocol to the channel Y in such a way that Y would become "self-correcting." 🫶

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

A physical message received on X' can now be characterized by a pair of a 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 a message for X on the physical channel X', and for this message 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, for 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 the synch-state R(X', CN, MSN) changes to R(X', CN+1, MSN). Notice that we have not yet said anything about the situation M.CN > R.CN. We'll describe a scheme for using this case to provide error correction on the control channel itself later 👑

2.4 EXCHANGE OF CONTROL INFORMATION 💌

So far we've discussed two schemes for the detection and retransmission aspects of the lost-message problem. In this section, we discuss methods by which the receiver communicates to the sender the fact of loss of messages.

We continue with the scenario developed in the above section, with a small change. For the purposes of the discussion that is about to follow, we'll assume there are actually two perfect channels available for exchange of control messages. One channel goes 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 to let R communicate the fact of loss of messages to S, we provide a 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 is of the following form:

LMR(X, CN, MSN)

where X is the name of the channel, CN is the new C-channel number, and MSN is the message sequence number of the lost message. If more than one message has been lost, then R uses the MSN of the first message only. When S receives this message, it can restart communication at the point where the break occurred, using the C-channel specified by the LMR message. This will restore the communication path X 🦋

What happens if S cannot restore communication at the break point because it no longer has the relevant messages? 😬 This issue can be solved in one of two ways: either let the protocol specify a fixed rule that S will be required to close the connection, or let the protocol allow S and R (and maybe the users on whose behalf S and R are communicating on X) to negotiate the action to be taken. For the protocol presented here, we've taken the approach that S may, at its option, either close the connection or negotiate with R. What action a specific host takes can either be built into its NCP or determined dynamically. Hosts that do not have very powerful machines will probably choose the static option of closing the connection; other hosts may make the decision depending upon the circumstances. For example, a host may decide that loss of messages is not acceptable during file transfers, whereas loss of a single message can be ignored for terminal output to interactive users. A host might even let the user processes decide the course of action to be taken. 🧚

If S determines that it cannot retransmit lost messages, it may want to let R decide what action is to be taken. If S so decides, then it may communicate this fact to R by transmitting a 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 the 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 the name of the C-channel obtained from the LMR message, MSN is the message sequence number of the first message in the sequence of lost messages, and COUNT is the number of messages in the sequence. S resets its own synch-state for connection X to S(X, CN, MSN+COUNT). Once S has informed R of its inability to retransmit lost messages, the burden of the decision falls on R, and S simply awaits R's reply before taking any action for the channel X 🫶

When R receives the LMS, it may either decide that loss is unacceptable and close the connection, or it may decide to let S continue. In the latter case, R informs S of its decision 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, S resumes transmission on X. To avoid the possibility of errors in the exchange of control messages, the LMA control message is specified to be an exact replica of the LMS control message, except for the message code, which determines whether a control message is LMA or LMS or something else 💖

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

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

In the above paragraph, we considered the situation in which R was able to detect the loss of messages. It is, however, possible that the last message transmitted on S->R is the one that gets lost. In this case, R will not be aware of the loss. In this situation, recovery can be initiated only if S can either positively determine, or simply suspect, that a message has been lost 🙈 In general, after having transmitted a control message, S would be expecting some sort of response from R. For example, if S transmits a Request-for-Connection (RFC) control message to R, S expects R to reply either with a Close (CLS) command or another RFC. If, after an appropriate time interval has elapsed and S has received no reply from R, our protocol specifies that S may retransmit the control message. In retransmitting, S must use the same C-channel and MSN values that were used for the original message. Since R can now receive duplicate copies, we stipulate that if R receives a duplicate of a message that it has already received, it may simply ignore the duplicate 🍓

2.6 SOME OTHER PROBLEMS 🧩

There are two problems that have not yet been solved. First, a sending host will usually have only a limited amount of buffer space in which it can save messages for possible later retransmission. So far, we have not provided any method by which a host may positively determine whether the receiver has correctly received a certain message or not. Thus it has no firm basis on which to decide to release the space used up by messages that have already been transmitted. The second problem is created by our recycling of the message sequence numbers. For the MSN mechanism to work correctly, it is essential that at any given instant of time there be no more than 15 messages in the

transmission path, bestie 💖 Like, if there were more than 15 messages floating around, some of them would have the SAME MSN and LRN 😭, and if one of them got lost you'd literally have no way to tell which one vanished 💀. ngl that's a whole disaster. The second problem shouldn't happen on the ARPA Network though, because the IMP sub-network won't let more than eight outstanding messages sit between any host pair (NWG-RFC #660) ✨

We can fix BOTH of these problems with one simple yet super flexible scheme 🦋 It adds two new control messages. The first is Request Status from Sender (RSS) 🎀, which the sending host uses to ask the receiver about its synch-state. The receiver answers with its copies of the C-channel number and MSN for a transmission path, sent in a Status from Receiver (SFR) control message over the control channel. SFR is a positive acknowledgement, but it's different from the usual ack schemes because here you only get one when somebody asks for it 🙈. Once the sender gets an SFR, it knows exactly which messages were properly delivered, and it may free the buffer space those messages were using 💅. RSS and SFR can also make sure there are never more than fifteen messages in the transmission path at any given time 👑

3.0 LOST MESSAGE DETECTION AND RECOVERY PROTOCOL 🩷

This protocol is an amendment to the Host-to-Host Protocol that lets hosts detect when messages get lost in the network 🕵️‍♀️, and it also gives them recovery procedures for those losses. It's split into two parts. Part 1 lays out the compatibility requirements. Part 2 is the new protocol itself, and it MUST be implemented by hosts that want to be able to recover from message loss in the network 🫶. You'll find lots of comments scattered through the description. These comments are NOT part of the protocol 🙅‍♀️. They're only there to help you understand it better, so no stress if you skim them.

The terminology is pretty similar to the Host-to-Host protocol. We talk about 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 it's established it's associated with a link (which is described by a link number). So the network connection is the logical communication path, and the link assigned to it is the physical one 🧚. On top of the links tied to network connections, there are "control-links" for sending "control commands" 💜. When we say "connection," it could mean either the network connection or its link, and the context tells you which. The word "links" covers the connection-associated links AND the control-links. Also, notice that a receiver of a connection can send control commands about that connection 👀.

3.1 DEFINTIONS 📖

3.1.1 HOST TYPE "A"

Hosts that haven't adopted Part 2 of this protocol amendment are known as type A hosts 🦕.

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

3.1.2 HOST TYPE "B"

Hosts that DO adopt Part 2 of this protocol amendment are known as type B hosts 🌟.

(Comment: Hmm, not a keyword here, just vibes.)

3.1.3 MESSAGE SEQUENCE NUMBER (MSN)

This is a four bit number attached to regular messages. It sits in bits 25 through 28 of the Host-to-IMP and IMP-to-Host leaders for regular messages [BBN Report No. 1822] 🔢. Type B hosts use it to detect message loss on a given link. Type A hosts always set the MSN (on the messages they send out) to zero 0️⃣. When a type B host is using it, the first message on a link (after the connection is established) has an MSN value of one. For each message after that, the MSN goes up by one until it hits 15. The message after 15 goes right back to one 🔁.

(Comments: Type B hosts will use the MSN mechanism only when they're talking to other type B hosts. If a type B host is talking to a type A host, it will basically simulate how a type A host behaves and use zero MSN values for that communication 🎭.)

The Link Resynch Number is an eight bit number tied to a link, and it's used to resynchronize the communication ✨. For links attached to a network connection (aka user links), it starts out at zero. For control links, it's set to zero when the Network Control Program (NCP) initializes. For a given link, the current LRN value gets copied into the LRN field of every message sent out on that link. Type B hosts MAY manipulate the LRN values, following the protocol described later 🛠️.

(Comments: Our protocol says that for ALL communication involving a type A host, the LRN value never changes from zero 🧊. The LRN field is currently unused, so all hosts set it to zero even if they don't recognize it as an LRN field. That's what keeps everything compatible 🫶.)

3.1.5 LRN FIELD

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

3.2 NEW CONTROL COMMANDS 🎀

3.2.1 LMR - LOST MESSAGE FROM RECEIVER

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

The LMR command is sent by a receiving host to tell the sending host that one or more messages were lost 🚨. The MSN field gives the message sequence number of the first message lost. The LRN field gives the NEW LRN value that MUST be used if and when communication is restored 🔄.

(Comments: As we'll see later, the LMR command also resets the bit and message allocation in the sending host to zero 🧹. To let a sender restore communication, an LMR command is usually paired with an allocate command. But these comments don't apply to control links, because there's no allocation mechanism for them 🙅‍♀️.)

3.2.2 LMS - LOST MESSAGE FROM SENDER

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

A sending host sends this command in reply to an LMR command if it (the sender) can't retransmit the lost messages that the LMR command specified 😬. The point of it is to ask the receiver whether losing those messages is acceptable. After sending this command, the sender waits for a reply before sending any messages over the link involved ⏳. This command MUST NOT be sent for control links 🚫. The LRN and MSN values are the same as the ones specified in the LMR command. COUNT tells you how many messages were lost 🔢.

3.2.3 LMA - LOSS OF MESSAGES ACCEPTABLE

This command is identical to the LMS command except for the command code 👯. When a receiver gets an LMS command, it MAY send this command back to the sender to say that losing the messages is acceptable 💅. All fields in this command are set to the corresponding values from the LMS command.

3.2.4 CLS2 - CLOSE2

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

The CLS2 command is like the current CLS command, except it has the new LRN and MSN fields 🆕. Both the receiving and sending hosts copy their LRN and MSN values into the CLS2 command. When a host gets a CLS2 command, it compares the LRN and MSN values in that command with its own values for the connection. If they don't match, an error has happened, and the host MAY start recovery procedures 🛟.

(Comments: The whole point of this command is to make sure the last message sent on a connection was received successfully 🎯.)

3.2.5 ECLS - ERROR CLOSE

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

The ECLS command is like the current CLS command 🫠. It's used for closing connections that have suffered an irrecoverable loss of messages 💔.

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

  1. A connection that hasn't been opened successfully yet can be closed with the CLS command. All connections involving type A hosts MUST be closed using the CLS command.
  2. Connections between type B hosts can be closed using the CLS2 command. A connection is only considered closed when matching CLS2 commands have been exchanged between the sender and the receiver 🤝.
  3. Connections between type B hosts that have suffered an irrecoverable loss of messages MUST be closed by the ECLS command 🚪.)

3.2.6 RSS - REQUEST STATUS FROM SENDER

____8_______8______
I      I        I
I RSS  I LINK   I
I_______I_________I_

A sending host MAY issue an RSS command to find out the status of transmission on a particular connection or on the control link 🔍.

3.2.7 RSR - REQUEST STATUS FROM RECEIVER

____8_________8_____
I       I        I
I RSR   I LINK   |
I________I_________I_

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

3.2.8 SFR - STATUS FROM RECEIVER

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

A receiving host MAY issue this command to tell the sender about the state of a particular connection or the control link 📣.

3.2.9 SFS - STATUS FROM SENDER

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

A sending host MAY issue this command to tell the receiver about the state of a particular connection or the control link 🗣️.

3.3 THE PROTOCOL 👑

3.3.1 PART ONE

All type A hosts MUST use zero MSN and LRN values on the messages they send out 0️⃣. When talking to a type A host, a type B host MUST simulate the behaviour of a type A host 🪞.

(Comments: This simulation is honestly not complicated at all 😌. All that's required is that hosts that adopt this protocol MUST NOT use it when communicating with hosts that haven't adopted it 🙅‍♀️.)

3.3.2 PART TWO

This part of the protocol is written as a set of rules that MUST be observed by all type B hosts when they're communicating with other type B hosts 📜.

3.3.2.1 RESPONSIBILITIES OF HOSTS AS SENDERS

(1). A type B sending host MUST use message sequence numbers on all regular messages it sends to other type B hosts, as specified in the definition of the message sequence numbers (Section 3.1.3) 🔢.

(2). A type B sending host MUST use link resynch numbers on all regular messages it sends to other type B hosts, as specified in the definition of link resynch

...number (Section 3.1.4). 🦋

(3) okay so a sending host MAY retransmit a message if it suspects that the message may have been lost in the network during previous transmission. 💖 retransmitting is totally a choice, bestie 🫶

(4) A sending host MAY issue an RSS command to the receiver to check the state of transmission on any link 👀✨

(5) A sending host MUST use the ECLS command to close a connection if that connection is being closed due to an irrecoverable transmission error. Otherwise, it MUST use the CLS2 command. 💀 this is the "we're done, no cap" moment 😭

3.3.2.2 RESPONSIBILITIES OF HOSTS AS RECEIVERS ✨

(1) A receiver host will keep track of LRN and MSN values for each link it receives messages on. The initial value of LRN will be zero, and the initial value of MSN will be one. For each receive link, the host SHOULD be prepared to receive a message with the LRN and MSN values specified by its tables. When the host has received the expected message on a given link, it will change its table MSN value as specified in the definition of MSN. 🌸

(2) On a given link, if a host receives a message with an LRN value smaller than the one in use, it will ignore the message. 🙈

(3) If a host receives a duplicate message (same LRN and MSN values), it will ignore the duplicate. 💅

(4) A host will examine the MSN values on all regular messages that it receives to detect loss of messages. If on any link one or more messages are found missing, it will focus on only the first message lost and take the following series of actions:

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

However, if a host does not want to initiate the recovery procedures, it MAY simply close the connection by an ECLS command. 🦋

(5) A receiver host MAY issue the RSR command to check the state of transmission on any link. 🧚

(6) If a connection is being closed due to an irrecoverable error, a receiving host MUST use the ECLS command. Otherwise it MUST use the CLS2 command. 👑

3.3.2.3 SENDING HOST'S RESPONSE TO CONTROL MESSAGES 💅

(1) RSR command: the sender MUST transmit a SFS command to the receiver for the link involved.

(2) ECLS command: The sender MUST cease transmission, if it has not already done so, and issue an ECLS command if it has not already issued either an ECLS or CLS2 command.

(3) CLS2 command: The sender MUST compare the LRN and MSN values of the CLS2 command with its own values of the LRN and MSN for the connection involved. If an error is indicated, it MAY either close the connection with an ECLS, or initiate recovery action as specified in the section 3.3.2.1. 🌈

(4) LMR command for a connection (i.e., not a control link): The sender MAY follow any one of the following three courses of action:

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

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

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

  1. Set the LRN to that specified in the LMR command and begin retransmission of lost messages.
  2. Set the LRN to that specified by the LMR command, and insert a Reset command at the break point.

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

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

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

3.3.2.4 RECEIVING HOST'S RESPONSE TO CONTROL MESSAGES 🌸

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

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

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

(4) LMS command: The receiver MAY take one of the following two courses of action:

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

(Comments: The protocol does not require the receiver to take any specific action with regard to a SFS command. However, a receiver host MAY use the information contained in it.) 💜

4.0 CONCLUDING REMARKS 🧚‍♀️

The design of this protocol has been governed by three major principles. First, we believe that to be useful within the ARPA Network, any new protocol MUST be compatible with the existing protocols, so that each host can make the transition to the new protocol at its own pace and without large investment. Secondly, the protocol SHOULD tie into the recovery mechanism of the IMP-to-Host Protocol. The price we pay for this is the small MSN field and a message oriented protocol rather than a byte stream oriented protocol. 🍓

The third consideration has been flexibility. While this protocol guarantees detection of lost messages, the philosophy behind the recovery procedures is that a host SHOULD have several options, each option providing a different degree of sophistication. A host can implement a recovery procedure that is most suitable for its needs and the capabilities of its machine. Even though two hosts may have implemented different recovery procedures, they can communicate with each other in a compatible way. In a network of independent machines of widely varying capabilities and requirements, this seems to be the only way of implementing such a protocol. 🌈

Even though this protocol provides a variety of options in a given error situation, the choice of a specific action MUST be consistent with the basic requirements of the communication path. For example, partial recovery is not acceptable during file transfers. We fully expect the File Transfer Protocol to specify that if an irrecoverable error occurs, the file transfer MUST be aborted. ✨ the end, besties ✨ 🎀

📦 where this page comes from