Browse Prior Art Database

Lost message detection and recovery protocol (RFC0663)

IP.com Disclosure Number: IPCOM000003721D
Original Publication Date: 1974-Nov-01
Included in the Prior Art Database: 2019-Feb-14
Document File: 19 page(s) / 28K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Kanodia: AUTHOR

Related Documents

10.17487/RFC0663: DOI

Abstract

Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 8% of the total text.

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

A LOST MESSAGE DETECTION AND RECOVERY PROTOCOL

1.0 INTRODUCTION

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

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

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

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

- 1 -

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

The protocol extension proposed here uses the four bits of the message sequence number in the message leader for detection of lost messages. However, to facilitate recovery, it uses another eight bit field (presently unused) in the 72 bit header of the regular messages. In the next section of this paper we discuss some of the...

Processing...
Loading...