Skip to content

Re-evaluate the served-peer liveness window (currently ~119s) #43

Description

@gustavovalverde

Follow-up from #42 (which closed #19).

Context

The seeder serves only peers zebra-network reports as recently live: MetaAddr::was_recently_live, which means Responded state with a last response inside MIN_PEER_RECONNECTION_DELAY (~119 seconds). That is a deliberately strict, high-quality signal, but it bounds the served set to roughly the seeder's current active outbound connection count. On sparse networks (testnet, IPv6) the servable set can be thin, which the ADR 004 consequences already flag.

Question

Should the seeder widen the freshness window while still excluding never-handshaked gossip? Options to evaluate:

  • Keep was_recently_live (~119s): highest quality, smallest set.
  • Require Responded state but accept a longer staleness, up to zebra's own gossip horizon (is_active_for_gossip, 3 hours). Still verified (handshaked at least once), larger set, but some peers may have dropped offline.

Acceptance

  • Measure seeder_peers_servable{addr_family} and seeder_peers_ineligible{reason="not_recently_live"} on mainnet and testnet under each window.
  • Pick a window that balances served-set size against the risk of handing out stale addresses, and document it in ADR 004.

Refs: ADR 004 in docs/architecture.md; the window is zebra-network's MIN_PEER_RECONNECTION_DELAY.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions