Goal
Remove the UDP banning service's bloom 0.3.2 counting Bloom filter if reproducible correctness, memory, and performance evidence shows that it adds no material value. Record an approved removal decision and evidence in an ADR so future maintainers understand why the service does not use a Bloom filter.
Context
The current ban service updates both a counting Bloom filter and an exact HashMap<IpAddr, u32> for every invalid connection-ID source. The map determines the final ban decision, so the Bloom filter does not bound exact-map memory. Its observable role is only to bypass an exact-map lookup when its estimate is at or below the threshold.
The direct bloom dependency is recorded as requiring qualified legal review in the dependency-license review. This issue investigates a technical remediation option only; it must not make a license-compatibility conclusion.
Scope
- Establish and test the current counter, threshold, reset, metrics, and validation-policy semantics.
- Add a focused Criterion benchmark comparing the current two-level
BanService with a benchmark-local exact-map-only reference.
- Measure
increase_counter and is_banned for repeated and distinct IPv4/IPv6 sources, threshold boundaries, and small, medium, and high map cardinalities.
- Measure allocations and retained memory under distinct-source IPv4 and IPv6 workloads until cleanup.
- Remove
bloom and simplify the service only if evidence shows no material benefit.
- Create an ADR for an approved removal, including the evidence and preserved exact-map decision semantics.
- Keep bounded-memory alternatives as separate follow-up designs. Any alternative accepting false negatives must state a measurable rate and obtain its own approved ADR before implementation.
Out of Scope
- Making a legal compatibility conclusion about
bloom.
- Implementing or copying an alternative Bloom filter.
- Changing validation policy, ban threshold semantics, or cleanup interval to favor a benchmark.
- Treating a direct exact-map design as a complete denial-of-service solution.
Verification
Run the focused UDP-core tests, the new Criterion benchmark, relevant UDP server/integration tests, linter all, and applicable pre-push checks. Record manual evidence for threshold/reset behavior, IPv4/IPv6 distinct-source memory, counter throughput, and strict versus disabled validation policy.
References
Goal
Remove the UDP banning service's
bloom0.3.2 counting Bloom filter if reproducible correctness, memory, and performance evidence shows that it adds no material value. Record an approved removal decision and evidence in an ADR so future maintainers understand why the service does not use a Bloom filter.Context
The current ban service updates both a counting Bloom filter and an exact
HashMap<IpAddr, u32>for every invalid connection-ID source. The map determines the final ban decision, so the Bloom filter does not bound exact-map memory. Its observable role is only to bypass an exact-map lookup when its estimate is at or below the threshold.The direct
bloomdependency is recorded as requiring qualified legal review in the dependency-license review. This issue investigates a technical remediation option only; it must not make a license-compatibility conclusion.Scope
BanServicewith a benchmark-local exact-map-only reference.increase_counterandis_bannedfor repeated and distinct IPv4/IPv6 sources, threshold boundaries, and small, medium, and high map cardinalities.bloomand simplify the service only if evidence shows no material benefit.Out of Scope
bloom.Verification
Run the focused UDP-core tests, the new Criterion benchmark, relevant UDP server/integration tests,
linter all, and applicable pre-push checks. Record manual evidence for threshold/reset behavior, IPv4/IPv6 distinct-source memory, counter throughput, and strict versus disabled validation policy.References
docs/issues/open/<assigned-number>-consider-removing-bloom-filter/ISSUE.md