Out-of-Band Control Signals in a Host-to-Host Protocol
RFC 721

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

NWG/RFC 721                                           1 SEP 76 LLG 36636
Out-of-Band Control Signals

Network Working Group                                      Larry Garlick
Request for Comments 721                                         SRI-ARC
NIC 36636                                                 1 September 76

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

This note addresses the problem of implementing a reliable out-of-band
signal for use in a host-to-host protocol.  It is motivated by the fact
that such a satisfactory mechanism does not exist in the Transmission
Control Protocol (TCP) of Cerf et. al. [reference 4, 6]  In addition to
discussing some requirements for such an out-of-band signal (interrupts)
and the implications for the implementation of the requirements, a
discussion of the problem for the TCP case will be presented.

While the ARPANET host-to-host protocol does not support reliable
transmission of either data or controls, it does meet the other
requirements we have for an out-of-band control signal and will be drawn
upon to provide a solution for the TCP case.

The TCP currently handles all data and controls on the same logical
channel.  To achieve reliable transmission, it provides positive
acknowledgement and retransmission of all data and most controls.  Since
interrupts are on the same channel as data, the TCP must flush data
whenever an interrupt is sent so as not to be subject to flow control.

Functional Requirements

   It is desirable to insure reliable delivery of an interrupt.  The
   sender must be assured that one and only one interrupt is delivered
   at the destination for each interrupt it sends.  The protocol need
   not be concerned about the order of delivery of interrupts to the
   user.

   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, whether or not other controls are being
   handled.  The interrupt should 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.  In fact, if
   coupling of the channels relies on the advancement of sequence
   numbers on the data-control channel, then the interrupt channel is no
   longer independent of flow control as required above.  The
   synchronization with the data stream can be performed by the user by

                                   1


NWG/RFC 721                                           1 SEP 76 LLG 36636
Out-of-Band Control Signals

   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 associate
   interrupt acknowledgements with the correct interrupt, some naming
   convention for interrupts is necessary.  Sequence numbers provide
   such a naming convention, along with the potential for providing an
   ordering mechanism.

   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 are
   from the same sequence number space as some other channel, then
   sending an interrupt can be 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 is dependent on
   the acknowledgement of all previous data.  The ARPANET protocol,
   while not providing for reliable transmission, does provide for the
   separation of the interrupt-control channel and the data channel.

Multiple Channels and Sequence Numbers

   If multiple channels are to be used for a connection, then it becomes
   interesting to determine how the sequence numbers of the channels can
   be coupled so that sequence number maintenance can be done
   efficiently.

   Assigning sequence numbers to each octet of data and control, as in
   the TCP, allows positive acknowledgement and ordering.  However,
   since packets are retransmitted on timeout, and since multi-path
   packet switch networks can cause a packet to stay around for a long
   time, the presence of duplicate packets and out-of-order packets must
   be accounted for.  A sequence number acceptability test must be
   performed on each packet received to determine if one of the