Summary

  • LTP lets a client mark a block prefix red for acknowledgment and retransmission, followed by a green suffix that is sent without either. A mixed block therefore contains two different promises inside one session.
  • A transmission-session completion notice proves that all bytes were transmitted and that the red part was reported received. It does not prove green-part reception, Bundle Protocol forwarding, destination application consumption or mission success.

Completion names two facts, not one outcome

Imagine a sender placing one block on a deep-space link. The block contains a compact control header followed by a larger body that can tolerate loss. The client marks the header red and the body green. Hours later the local dashboard shows the LTP session as complete. An operator reads the word “complete” and closes the delivery ticket.

RFC 5326 does not authorize that conclusion. Its transmission-session completion procedure waits for two conditions. First, the sender must know that all block data have been transmitted. The operating environment signals this when the end-of-block segment is dequeued for actual transmission. Second, accumulated reception reports must show that the entire non-empty red part was received. The resulting client notice carries the session ID and states exactly those facts.

The green suffix is absent from the assurance condition. It was transmitted, but no reception report covers it and no retransmission repairs it. The receiver may have obtained every green byte, some of them or none. A completion label that omits the red length turns a scoped guarantee into an unqualified verdict.

This is not a flaw hidden in a corner case. It is LTP's central allocation mechanism. A client decides how much of the block merits scarce retransmission effort. A fully red block can make session completion coincide with reported reception of the whole block. A mixed block cannot. A fully green block can complete without any data acknowledgment at all. The same status word therefore has different evidentiary content depending on a field chosen before transmission.

The defensible record is not session=complete. It is: block length, red length, all-original-bytes-transmitted receipt, reception-report coverage for the red prefix, missing green offsets if observable, and the higher-layer status that followed.

Red and green are treatment classes, not priority labels

RFC 5326 defines the red part as a block prefix subject to acknowledgment and retransmission. The green part, when present, is the suffix immediately after it and is transmitted without either. RFC 5325 adds an important warning: red does not mean urgent or more important. It means the client requested reliable link transmission for those bytes.

An application might place metadata in red because the green payload is useless without it. It might instead make the whole block red because every byte is essential, or the whole block green because timeliness matters more than repair. Those are application decisions. LTP executes them; it does not infer business value from content.

The boundary is encoded in segmentation. A data segment contains only red data or only green data. End of red part, EORP, fixes the red length. End of block, EOB, fixes the whole length. If a nominal boundary falls inside a link-sized segment, an implementation may treat the remaining bytes in that segment as red for efficiency. That operational promotion changes which bytes receive retransmission treatment and belongs in the evidence record.

“The header was reliable” is therefore insufficient. Which octets were red in the actual segmentation? Did EORP and EOB occur in the same segment? Was part of the intended green suffix promoted? A decision made against an abstract payload map can diverge from what the engine placed under the red promise.

The prefix/suffix rule also creates a protocol invariant. Red cannot resume after green begins. If a receiver sees red above a previously observed green offset, or green below a red offset, RFC 5326 treats the segment as miscolored, discards it and initiates cancellation. Color is not a decorative tag. It defines the shape of the reliability contract.

Five notices describe five different moments

Operational systems often compress several LTP notices into one “sent” or “delivered” state. The specification keeps them separate because their actors and proof scopes differ.

A green-part segment arrival notice is produced at the receiving engine for each green segment. It includes the segment bytes, block offset, length, source engine and whether the segment reaches EOB. One green notice does not prove neighboring green segments arrived. Even the EOB-marked green segment proves the block's end position, not the receipt of every preceding green offset.

A red-part reception notice is also receiver-side. It occurs after EORP has established the red length and every red byte is present. The local client service receives the red bytes and learns whether the red end is also the block end. That last indication matters: if it is false, the receiver has completed only the reliable prefix of a mixed block.

An initial-transmission completion notice is sender-side. It says all original red and green segments have been transmitted. RFC 5326 explicitly warns that lost red segments may still require retransmission. This receipt closes the first pass, not the reliability cycle.

A transmission-session completion notice is stronger. All bytes have been transmitted and the red part is known through report claims to have arrived. It still says nothing about missing green bytes.

A cancellation notice is different again. It records termination by the peer, an error, a retransmission-limit event or local resource pressure. For transmission-side cancellation, the RFC states that there is no assurance the destination client service received any part of the block. A cancellation acknowledgment confirms the cancellation segment, not the payload that preceded it.

A status model that preserves these events can answer useful questions. Did the remote engine receive the reliable prefix? Which green segments reached the receiving client? Did the sender merely finish the first pass? Was the session closed after the reliability condition, or abandoned after a limit? A single completion bit cannot.

A reception report is bounded evidence

LTP uses checkpoints and reception reports to avoid treating silence as loss over very long delays. A checkpoint asks the receiver to report. The report identifies lower and upper bounds and lists received ranges within that scope. Its claims can be combined with earlier reports to establish full reception of the red part.

The bounds are essential. A report that covers offsets 1,000 through 6,000 and claims 1,000 through 5,000 does not say anything about the first thousand bytes or bytes above 6,000. A storage system that saves only the positive interval loses the difference between “not received” and “outside this report”.

Large or fragmented reception state may require multiple report segments. Each has its own serial number and can stand alone over its own scope. Completion is a union judgment over compatible claims tied to the same session, not the existence of one optimistic report.

Report acknowledgments create another tempting category error. Their content is simply the serial number of the report being acknowledged. The acknowledgment tells the receiver that its report arrived at the sender so the receiver can stop retransmitting that report. It does not acknowledge data at the receiver, and it certainly does not acknowledge application consumption. The direction of proof matters.

For audit, retain checkpoint ID, report serial, lower and upper bounds, reception claims, report generation and the report acknowledgment separately. If a summary says “acknowledged”, it must name which object was acknowledged and by whom.

The clock comes from outside the protocol

Ordinary transport intuition treats a timer as elapsed wall time since a packet left. LTP's timers depend on communication opportunities. The operating environment must tell the engine when transmission to a peer begins or stops, when transmission from the peer begins or stops, the current one-way light time and the expected transmission rate.

A checkpoint timer starts from a link-state cue that the checkpoint was dequeued for actual transmission, not merely placed in an application queue. A report timer likewise starts when the report begins transmission. When the remote engine is known to have stopped transmitting, relevant timers are suspended; they resume when the contact window returns.

This moves part of protocol correctness into a schedule and telemetry boundary. A late report may reflect propagation, a contact pause, a stale link cue, an incorrect distance estimate, queue delay or real loss. The timer event alone cannot choose among them.

It also means that the actor who controls contact plans, light-time estimates and queue cues controls when the protocol declares a timeout. That authority should be visible. A dashboard that presents retransmission-limit cancellation without the cue history attributes a locally constructed timing decision to the remote engine.

Link completion stops below the application

LTP engine IDs identify engines within a closed communicating set. A convergence-layer adapter may map those IDs to Bundle Protocol endpoints, but the mapping is implementation-specific. An engine is not automatically a user, legal principal, spacecraft application or final destination.

The receiving LTP client is commonly a higher-layer protocol such as Bundle Protocol. Receiving a red part at that client proves that bytes crossed one LTP link under one session. The bundle may still wait in persistent storage, expire, fail a later hop, encounter a security rejection or never reach the destination application. RFC 4838 and later Bundle Protocol work make store-and-forward state explicit precisely because a challenged network cannot reduce delivery to a continuous end-to-end connection.

The reverse confusion is equally risky. Failure of an LTP session does not prove the mission payload was lost forever. Another contact, copy, route, custodian or application recovery path may exist. Link-layer evidence should neither overclaim success nor overclaim final failure.

RFC 5326 also relies on the underlying link not to deliver incomplete segments and, absent LTP authentication, to detect and discard corruption. RFC 5327 adds authentication and cookie mechanisms intended to reduce denial-of-service risks. Integrity, origin authentication, freshness and completeness are different axes. A cryptographically acceptable report can still cover only the red prefix. A complete red prefix can still belong to a block whose green suffix was lost.

The deployment boundary is part of the fact

RFC 5326 is Experimental. Its IESG note says publication was not based on IETF review for security, congestion control or interaction with deployed protocols. The document itself contains no flow-control or congestion-control mechanism and says LTP is not appropriate for ubiquitous global-Internet use. Under that version, LTP over UDP is limited to development or private LANs.

Later documents provide registries, datagram carriage guidance and a newer Bundle Protocol. Those are useful continuity records, not proof that a particular deployment conformed to RFC 5326, used mixed red/green blocks or achieved a measured result. Authors' institutional affiliations likewise establish provenance, not current agency or adoption.

An operator evaluating LTP must therefore record the exact specification profile, underlying link contract, authentication extensions, management limits and higher-layer integration. “Uses LTP” is too broad to support a reliability claim.

Sources and evidence boundary

These sources establish protocol semantics, publication status, surrounding architecture and registry history. They do not establish a current LTP deployment, a spacecraft result, implementation conformance, a complete green suffix, Bundle delivery or application consumption.