Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

Lost message detection and recovery protocol (RFC0663)

IP.com Disclosure Number: IPCOM000003721D
Original Publication Date: 1974-Nov-29
Included in the Prior Art Database: 2000-Sep-13
Document File: 17 page(s) / 44K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Kanodia: AUTHOR

Abstract

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

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 7% 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 de...