Summary
- RFC 1986 grouped many packets into a buffer and burst so one costly channel access could carry substantial data; the receiver answered the buffer once, naming only missing packet numbers.
CONTROL_OK,CONTROL_RESEND, highest consecutive control sequence andNULL-ACKwere precise local receipts, but none alone proved whole-file completion, peer identity, security or the cause of loss.- The 1993 results showed one experimental point-to-point setup, not general adoption. The RFC itself said authentication was absent and security had been overlooked.
One acknowledgement could cost another synchronization
RFC 1986 starts from a physical fact. In the described tactical satellite path, radio and cryptographic synchronization took about 1.25 seconds before transmission. Satellite propagation added roughly another half-second to a round trip. On a half-duplex link, a reply was not a cheap packet travelling alongside data. It meant dropping one direction, rebuilding the other and consuming another access to the channel.
ETFTP therefore treated direction changes as a budget. A file was read into buffers; each buffer was divided into blocks; blocks became DATA packets; packets were concatenated into bursts. The last block of a buffer was marked LDATA. Instead of acknowledging each packet, the receiver replied at the buffer boundary. If the buffer was complete, it sent CONTROL_OK. If holes remained, CONTROL_RESEND carried the buffer number and the explicit packet numbers to send again.
This was not simply “fewer ACKs.” It changed the unit of evidence. A packet checksum described one datagram. A missing-packet list described the receiver’s present view of one buffer. An OK closed that buffer. Final transfer closure still required the sender’s QUIT and the receiver’s DONE.
Buffer, burst and packet were different controls
The distinction among those three units mattered. A larger buffer reduced the number of acknowledgement boundaries and therefore the number of channel reversals. A larger burst kept the transmitter keyed while several packets entered the path. Packet size traded overhead against error exposure: large packets could improve throughput on a clean path but cost more when a high bit-error rate damaged them.
RFC 1986 made the parameters adjustable. With automatic adaptation enabled, a buffer in which at least half the blocks needed retransmission triggered a downward sequence: halve packet size, then reduce burst size, then reduce the offered burst rate toward the measured tight-timer rate. If 99 percent of packets arrived without retransmission, packet size could be offered upward. CONTROL_OK carried proposed new values, and the sender used NULL-ACK to confirm a valid change.
That exchange formed a small deterministic common layer. Both implementations could inspect buffer number, missing packet numbers and proposed parameter values. Yet confirmation was not execution proof. A NULL-ACK showed that the sender accepted a change request; only the next packets could show that both sides applied it at the same boundary.
A consecutive number was not a complete file
DATA and LDATA packets carried the highest consecutive CONTROL sequence number received. That field helped the control side know which contiguous prefix of messages had been observed. It did not say that every data packet had arrived, that every later control message existed, or that the advertised file length matched what reached disk.
The same discipline applies to CONTROL_RESEND. It proved that, under the receiver’s current buffer state, named packet numbers were absent. It did not prove the sender never emitted them. It could not distinguish radio errors from contention, queue overflow, timing error or implementation delay. The timers were also estimates: baud rate and radio delay were supplied or inferred, while repeated read timeouts added five seconds linearly. A timeout was evidence of an unmet timing expectation, not a diagnosis.
Read through Lu Heng’s Running-Code Primacy, the important separation is between a published format and an executed transition. RFC 1986 could specify exactly what a receipt meant. Operators still needed traffic and state evidence to show that the implementation honoured that meaning.
The experiment was narrower than the lesson
The performance tables came from a 101,306-byte file crossing a 16 kbps encrypted path. The radios were connected through coaxial cable for what the authors called a clean 10e-5 BER link. The highest reported table result was 10,432 bps with a 131,072-byte buffer, 2,048-byte packets and sixteen packets per burst. Those figures included connection, recovery and disconnection time from the user’s perspective.
They were useful results, but bounded ones. They did not establish multicast behaviour, shared-channel fairness, modern wireless performance or widespread deployment. The document itself warned that a point-to-point persistence setting would not be appropriate when more users shared the channel. It also contained a revealing packet-size tension: the tunable range was stated as 16 to 1,448 user bytes, while test tables included 2,048-byte packets. The record should preserve that inconsistency rather than quietly repair it.
Security was not an implied property waiting to be inferred. RFC 1986 said ETFTP had no user/password validation, repeated TFTP’s security problems, and used a root-owned setuid server in the prototype. Connection IDs, ports, checksums and sequence values correlated protocol state; they did not authenticate a person or authorize a file operation.
The durable contribution of RFC 1986 was to make a hidden physical expense visible in protocol structure. It bought long data runs with fewer reversals and repaired holes with a compact list. Its receipts were valuable precisely because their claims were limited. A buffer OK was a buffer OK. Completion, identity, cause and security remained separate facts.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
