[GH-ISSUE #95] perf(p2p): bound catalog lookup latency across multiple peers #31

New issue

Closed

opened 2026-10-29 14:18:36 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-29 14:18:36 +00:00

Owner

Originally created by @catyans on GitHub (Jul 31, 2026).
Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/95

Problem

IrohBlobsP2pTransport::lookup_peers currently queries candidate peers
sequentially. Each remote lookup has its own timeout (5 seconds by default), so
stale or unreachable peers at the front of the scheduler-provided list can make
catalog lookup latency grow linearly with the number of failed candidates.

The implementation already calls this out with:

// TODO: parallelize lookups to multiple peers.

This affects both scheduler-index hits and broad peer-discovery fallback.

Proposed change

Run remote catalog lookups with a small fixed concurrency bound while retaining
the scheduler-provided ordering when selecting a successful descriptor.

Check local/self candidates without network I/O.
Keep at most a bounded number of remote lookups in flight.
Yield results in candidate order so a slower, higher-priority peer still wins
over a lower-priority peer in the same window.
Continue past misses, timeouts, and malformed/unreachable peers.
Avoid adding a user-facing tuning knob until measurements show one is needed.

This reduces worst-case lookup time from approximately N * lookup_timeout to
ceil(N / concurrency) * lookup_timeout without generating an unbounded
connection burst or discarding scheduler priority.

Validation

Unit tests for ordering, bounded concurrency, misses, and errors.
Existing Iroh loopback lookup/fetch tests.
Multi-node Lingjun experiment with failed candidates preceding a valid
provider, comparing lookup latency before and after the change.

Originally created by @catyans on GitHub (Jul 31, 2026). Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/95 ## Problem `IrohBlobsP2pTransport::lookup_peers` currently queries candidate peers sequentially. Each remote lookup has its own timeout (5 seconds by default), so stale or unreachable peers at the front of the scheduler-provided list can make catalog lookup latency grow linearly with the number of failed candidates. The implementation already calls this out with: ```rust // TODO: parallelize lookups to multiple peers. ``` This affects both scheduler-index hits and broad peer-discovery fallback. ## Proposed change Run remote catalog lookups with a small fixed concurrency bound while retaining the scheduler-provided ordering when selecting a successful descriptor. - Check local/self candidates without network I/O. - Keep at most a bounded number of remote lookups in flight. - Yield results in candidate order so a slower, higher-priority peer still wins over a lower-priority peer in the same window. - Continue past misses, timeouts, and malformed/unreachable peers. - Avoid adding a user-facing tuning knob until measurements show one is needed. This reduces worst-case lookup time from approximately `N * lookup_timeout` to `ceil(N / concurrency) * lookup_timeout` without generating an unbounded connection burst or discarding scheduler priority. ## Validation - Unit tests for ordering, bounded concurrency, misses, and errors. - Existing Iroh loopback lookup/fetch tests. - Multi-node Lingjun experiment with failed candidates preceding a valid provider, comparing lookup latency before and after the change.

bsakaguchi closed this issue

2026-10-29 14:18:36 +00:00

bsakaguchi referenced this issue

2026-10-29 14:19:06 +00:00

[GH-ISSUE #211] Add native E2B-compatible persistent volumes #67