Skip to main content

SRSPP

SRSPP is a lightweight reliable transport protocol built on top of CCSDS Space Packets. It provides reliable, ordered delivery of messages over unreliable links with minimal overhead.

How It Works​

How streams are created. SRSPP is connectionless — there is no handshake. A sender transmits immediately; a receiver accepts data from any sender automatically. This avoids wasting a round-trip on connection setup, which matters when contact windows are short and latency is high. The receiver maintains a separate stream for each sender it hears from. When a packet arrives from a new source address, the receiver creates a stream with its own sequence tracking, reorder buffer, and ACK state. Up to a configurable maximum number of streams can be active simultaneously. Each stream is identified by the pair of source address (from the SRSPP header) and destination APID (from the SPP header).

How data is sent. Within each stream, the sender breaks a message into packets, assigns each a sequence number, and transmits them. It keeps a copy of each packet until the receiver acknowledges it. If an acknowledgment doesn't arrive within a timeout, the sender retransmits.

How the sender knows what arrived. The receiver collects packets, reorders them by sequence number, and reassembles the original message. It sends acknowledgments back to the sender: a cumulative ACK says "I have everything up to packet N," and a selective bitmap says "I also have these specific packets beyond N." This tells the sender exactly which packets are missing so it only retransmits those.

How the sender avoids overwhelming the receiver. A sliding window limits how many packets can be in flight at once, preventing the sender from overwhelming the receiver or the network.

How streams are stopped. The sender transmits an EOS (End of Stream) packet with its own sequence number. The receiver acknowledges it like a data packet. Once the EOS is ACKed, both sides know the transfer is complete and can release resources for that stream.

Failure Scenarios​

  • Packet lost — the sender's retransmission timer expires. It resends the packet and restarts the timer. If the packet is lost again, it retries up to the maximum retransmit count (default 3). After that, the packet is declared lost and the application is notified.
  • Receiver unreachable — the retransmission timeout (RTO) determines how long the sender waits. A fixed RTO works for stable ISL links. An orbit-aware RTO adapts to contact schedules — if the receiver is behind the horizon, the sender waits until the next contact window instead of burning through retransmit attempts during a predictable gap.
  • Out-of-order arrival — the receiver buffers out-of-order packets and reports them in the selective ACK bitmap. The sender does not retransmit these. Only the gap (the missing packet) is retransmitted.
  • Message too large — messages exceeding the MTU are split into segments (FIRST / CONTINUATION / LAST). The receiver reassembles them in sequence order. If any segment is lost, only that segment is retransmitted — not the entire message.

Why No Handshake?​

SRSPP has no connection setup or liveness check. The sender can transmit data immediately without waiting for a round-trip confirmation that the receiver exists.

This design choice is motivated by space link characteristics:

  • High latency — handshakes add significant delay on links with multi-second round-trips. In the worst case, a satellite may pass out of range before a handshake completes.
  • Known endpoints — mission configurations define who communicates with whom.
  • Scheduled contacts — ground stations know when satellites are reachable.

The tradeoff is that sending to an unreachable receiver wastes time until packets hit the maximum retransmit count. The application receives packet loss notifications and can decide when to abort. This optimizes for the common case (receiver is reachable) rather than the failure case.

Design Goals​

  • Minimal overhead — reuses existing SPP header fields (sequence count, sequence flags)
  • No congestion control — designed for point-to-point links with predictable latency
  • Simple implementation — suitable for resource-constrained flight software
  • Efficient ACKs — combined cumulative and selective acknowledgment
  • No handshake — data is sent immediately without connection establishment

Sub-pages​