Reallocation in Case of Input Error
How to recover buffer space when messages arrive with errors.
Schipper, T., "Reallocation in Case of Input Error", RFC 71, DOI 10.17487/RFC0071, September 1970, <https://www.rfc-editor.org/info/rfc71>.
@misc{rfc71,
series = {Request for Comments},
number = 71,
howpublished = {RFC 71},
publisher = {RFC Editor},
doi = {10.17487/RFC0071},
url = {https://www.rfc-editor.org/info/rfc71},
author = {T. Schipper},
title = {{Reallocation in Case of Input Error}},
pagetotal = 1,
year = 1970,
month = sep,
} RFC text
Network Working Group Tjaart Schipper
Request for Comments #71 25 September 1970
UCLA-CCN
Reallocation in Case of Input Error
In case of reading a message from the IMP, it may be impossible for the
receiving NCP to determine the length of the message if an input error
occurs. The following protocol will be used at the CCN-Host at UCLA to
resynchronize flow control.
If an input error is detected and the NCP can find the intended link
number, it will send a GVB with frac = O to the sending Host and disregard
further incoming messages on that link. When the RET has been received, a
new ALL will be sent.
If the sending Host is not waiting for a RFNM when the GVB arrives, it will
send the RET immediately. If it is waiting for a RFNM corresponding to the
message with the error or a RFNM corresponding to a following message, it
will send the RET after the RFNM has been received.
In this way, the receiving Host will know that the link is clear before it
issues a new ALL.
TS/rb.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alexandra Weikert 7/97]
AI ELI5
On this page
§1The Error Recovery Problem
Tjaart Schipper from UCLA-CCN describes a procedure for the UCLA CCN Host to use when recovering from input errors in flow control. If corruption or noise occurs during message reception from the IMP, the receiving NCP may be unable to determine where the message ends. This leaves the buffer allocation in an inconsistent state—space has been reserved but the message is incomplete.
If a message gets garbled, the receiver does not know how much space it took up or whether the rest of the message is coming.
§2Recovery Procedure
When an input error is detected and the intended link number can be identified, the receiving NCP takes the following steps:
First, send a GVB (with frac = 0) to the sending host, instructing it to stop transmissions on that link. Then disregard all further incoming messages on that link until the error is resolved.
The sending host's behavior depends on its state. If it is not waiting for an RFNM when the GVB arrives, it sends RET (return) immediately. If it is waiting for an RFNM corresponding to the message with the error, or an RFNM for a subsequent message, it sends RET only after the RFNM has been received. This ensures that in-flight messages are acknowledged before the link is considered clear.
Once RET is received, the receiving NCP issues a new ALL (allocation) on that link to begin accepting messages again.
Say 'stop', wait for the other side to say 'OK I have stopped and saved my place', then tell them 'now you can send again'. This makes sure both sides agree the link is clean.
§3Why This Matters
This recovery procedure is essential for maintaining flow control consistency in the presence of errors. If a message arrives corrupted and the receiver does not know its true length, the pre-allocated buffer space becomes unusable—it is neither fully consumed nor available for new allocations. The GVB/RET/ALL sequence resynchronizes both hosts.
The key is waiting for in-flight RFNM acknowledgments before considering the link clear. This prevents the sending host from transmitting new messages while the receiver is in an undefined state.
Both sides need to agree that things are OK again before continuing. It is like a handshake: 'stop?', 'stopped', 'thanks, we can restart now'.