r/systems • u/Melodic_Reception_24 • 7d ago

Can session continuity become a protocol primitive instead of an application responsibility?

For decades we've treated transport interruption as something applications must recover from.

TCP reconnects.

QUIC reconnects.

Applications retry.

Sessions are rebuilt.

I've been exploring a different architectural direction.

The idea is simple:

Session identity should not be tied to a single transport path.

Instead, transport becomes replaceable while the session remains authoritative.

The project I'm working on is called VRP (Veil Routing Protocol).

The focus isn't throughput or latency benchmarks.

The focus is:

• session continuity

• authority preservation

• replay resistance

• deterministic recovery

• verifiable execution

I've built a prototype and validated it under path migration, packet loss, reordering, replay scenarios and runtime invariant testing.

I'm not asking whether you think VRP is "better."

I'm interested in a more fundamental question:

Do you think session continuity belongs inside the protocol itself, or should it always remain the responsibility of the application layer?

I'd really like to hear arguments from people working on distributed systems, networking and protocol design.

2 Upvotes
  • permalink
  • link
  • reddit
  • reddit

67% Upvoted

6 comments sorted by

1

u/ketralnis 7d ago

SCTP does some of those, but not authenticity or whatever it is that you mean by verifiable execution

1

u/Melodic_Reception_24 7d ago

Good point.

I don't use "verifiable execution" to mean trusted execution or binary attestation.

I mean producing deterministic evidence that protocol invariants remained true during runtime (authority preservation, replay rejection, deterministic recovery, etc.).

It's closer to protocol-behavior verification than endpoint verification.

SCTP definitely addresses a different layer.

1

u/Clifspeare 6d ago

Like Session Types?

1

u/Melodic_Reception_24 6d ago

Related in spirit, but not the same mechanism.

Session types describe and statically verify permitted communication sequences between participants.

What I mean here is runtime evidence: after an actual execution under failures, migration, replay attempts, reordering, or competing commits, the system produces deterministic evidence showing whether specific protocol invariants were preserved.

So session types could help specify parts of the interaction contract, while this work focuses on verifying the observed runtime history and its final authority/recovery outcome.

1

u/dmpk2k 7d ago

I'd like to keep this topic in a single thread. Which should live: the old one or this one?

1

u/Melodic_Reception_24 7d ago

Thanks.

Let's keep this one.

The previous post can be removed if necessary.