RFC 721

Out-of-Band Control Signals in a Host-to-Host Protocol ✨

Okay bestie, this is RFC 721, a Network Working Group Request for Comments by Larry Garlick of SRI-ARC 🎀 It's NIC 36636 and it's dated 1 September 76. The header also stamps it as NWG/RFC 721 with LLG 36636 (very 1976 📼). The title block doesn't name a category or status, and it doesn't say it obsoletes or updates anything, so there's nothing else to report there 💅

Okay so this note is about building a reliable out-of-band signal for a host-to-host protocol 🦋 Why? Because TCP (from Cerf et. al. [reference 4, 6]) doesn't have a satisfactory one, and that's the whole drama 😭 The note goes through some requirements for this out-of-band signal (aka interrupts 🔥) and what those requirements mean for implementing it. Then it looks at the TCP case.

ngl the ARPANET host-to-host protocol doesn't do reliable transmission of data or controls 💀 But it does meet the other requirements we want for an out-of-band control signal, so we're gonna borrow from it to solve the TCP case 🧚

Right now TCP handles all data and controls on the same logical channel 🎀 To stay reliable, it gives positive acknowledgement and retransmission for basically all data and most controls. But since interrupts live on the same channel as data, TCP has to flush data every time an interrupt is sent, so the interrupt isn't stuck behind flow control 🫶

Functional Requirements

It's desirable to insure reliable delivery of an interrupt 💖 The sender must be assured that one and only one interrupt gets delivered at the destination for each interrupt it sends. Like, exactly one, no more and no less 🔒 The protocol need not be concerned about the order of delivery of interrupts to the user, which is honestly a relief 🙈

The interrupt signal must be independent of data flow control mechanisms 👑 An interrupt must be delivered whether or not there are buffers provided for data, and whether or not other controls are being handled. It should also not interfere with the reliable delivery of other data and controls ✨

The host-to-host protocol need not provide synchronization between the interrupt channel and the data-control channel. Here's the catch: if coupling the channels relies on sequence numbers advancing on the data-control channel, then the interrupt channel is no longer independent of flow control, which we already said it must be 😤 The user can handle syncing with the data stream by marking the data stream when an interrupt is generated 🧁 The interrupt need not be coupled with other controls, since it in no way affects the state of a connection.

Once the interrupt has been delivered to the user, no other semantics are associated with it at the host-to-host level 🌸

Implications

To provide for reliable delivery and accountability of interrupt delivery, an acknowledgement scheme is required 📬 To match interrupt acknowledgements with the correct interrupt, some naming convention for interrupts is necessary. Sequence numbers provide that naming convention, plus the potential for an ordering mechanism too 🍓

A separate interrupt channel is required to make interrupts independent of flow control 🦋 A separate sequence number space for naming interrupts is also necessary. If the sequence numbers come from the same space as some other channel, then sending an interrupt can get blocked by the need to resynchronize the sequence numbers on that channel 😩

In the current TCP, which uses one channel for data, controls, and interrupts, flushing of data is combined with the interrupt to bypass the flow control mechanism. However, flushing of resynchronization controls is not allowed, and receipt of these controls depends on the acknowledgement of all previous data 🙅‍♀️ The ARPANET protocol doesn't provide reliable transmission, but it does provide for separating the interrupt-control channel from the data channel 💜

Multiple Channels and Sequence Numbers

If multiple channels are going to be used for a connection, then it gets interesting to figure out how the sequence numbers of those channels can be coupled so that sequence number maintenance can be done efficiently 🧠

Assigning sequence numbers to each octet of data and control, like TCP does, allows positive acknowledgement and ordering 💅 But packets get retransmitted on timeout, and multi-path packet switch networks can let a packet hang around for a long time. So duplicate packets and out-of-order packets must be accounted for 👀 A sequence number acceptability test must be performed on each packet received to decide which of these actions should be taken:

• Acknowledge the packet and pass it on to the user.
• Acknowledge the packet, but do not send it to the user, since it has already been delivered.
• Discard the packet; the sequence number is not believable.

To be continued in part 2 🎀💖

References ✨

Okay bestie, here are the receipts 🧾💅 every source this doc leaned on, with all the deets so you can go read them yourself 🤓📚

(1)  J. Postel, L. Garlick, R. Rom, "TCP Specification (AUTODIN II),"
     ARC Catalog #35938, July 1976.

(2)  R. Tomlinson, "Selecting Sequence Numbers," INWG Protocol Note
     #2, September 1974.

(3)  Y. Dalal, "More on Selecting Sequence Numbers," INWG Protocol
     Note #4, October 1974.

(4)  V. Cerf, Y. Dalal, C. Sunshine, "Specification of Internet
     Transmission Control Program," INWG General Note #72, December
     1974 (Revised). [Also as RFC 675, NIC Catalog #31505.]

(5)  Cerf, V., "TCP Resynchronization," SU-DSL Technical Note #79,
     January 1976.

(6)  Cerf, V. and R. Kahn, "A Protocol for Packet Network
     Intercommunication," IEEE Transactions on Communication, Vol
     COM-20, No. 5, May 1974.

(7)  C. Sunshine, "Interprocess Communication Protocols for Computer
     Networks," Digital Systems Laboratory Technical Note #105,
     December 1975.

And that's the whole thing, bestie 🦋 we're on page 7, the last page, so you're officially done 🎀🌸 no cap, that's a LOT of history for one little doc 😭✨