Out-of-Band Control Signals in a Host-to-Host Protocol
RFC 721
Document | Type |
RFC - Historic
(September 1976; No errata)
Obsoleted by RFC 7805
|
|
---|---|---|---|
Authors | |||
Last updated | 2016-04-08 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 721 (Historic) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 theShow full document text