Browse Prior Art Database

Lost message detection (RFC0516)

IP.com Disclosure Number: IPCOM000003642D
Original Publication Date: 1973-May-18
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR

Abstract

I have three suggestions for detecting the loss of messages by the communications subsystem. The first of these is perhaps the more powerful and simpler to implement since it uses no new concepts and has the power to retransmit the message detected as lost.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 77% of the total text.

Network Working Group Jonathan B. Postel

RFC # 516 UCLA-NMC

NIC # 16683 May 18, 1973

LOST MESSAGE DETECTION

I have three suggestions for detecting the loss of messages by the

communications subsystem. The first of these is perhaps the more

powerful and simpler to implement since it uses no new concepts and has

the power to retransmit the message detected as lost.

The first scheme:

If upon sending a message the host saved a copy of that message and

waited until either:

a RFNM was returned, in which case everything is ok and the next

message is processed.

a INCOMPLETE TRANSMISSION is returned, in which case the copy of

the message is retransmitted (this could be a loop so put a

finite upper bound on the number of times to retransmit the same

message).

a DESTINATION DEAD is returned, in which case mark the

destination down and require the exchange of reset commands

before further communication is allowed.

something else is received indicating an error in the network or

local IMP, in which case at least log the error, and probably

close the conversation.

Following the above procedures either on a per host basis or a per

link basis should prevent a lost message problem from

developing.

The second scheme:

If on a per host basis, message numbers are included in the host to

host header of messages,, and messages are delivered in order (this

is currently the case in the network, except for priority messages

so this proposal requires that each host either send everything as

priority or nothing as priority) then each receiving host can detect

a missing message by comparing the message number of the received

message with the previously received message.

On exchanging resets the sequence numbers between that pair of

hosts is set to zero.

Each time a message is sent the current send message number is

entered into a field in the message header, and the current send

message number is incremented (modulo N, say N=256)

Each time a message is received the message number from the

message is compared to the current receive message number and:

if the received message is the expected one then the message

is acceptable and current receive message number is

incremented (modulo N);

if the received message is not the expected one then a

message has been lost.

What to do when a missing message is detected, not clear, but at

least can be logged and reported to the network control center. A

missing message may not be fatal to an interactive conversation, but

it is critical in a file transfer, thus I suggest that missing

messages which are not recovered be cause to close the conversation.

The third scheme:

Host to hos...