Enforce aggregate user and target-group egress budgets #66

Problem

Destination accounting is keyed by exact destination strings. Separate addresses, aliases or cooperating users can be individually admitted without sharing an operator-defined target-group or user traffic budget.

Proposed change

Add explicit aggregate user/node/target-group network rate and volume budgets in addition to per-destination and per-run allocations. Account concurrent-work and queued-storage admission remain separate controls.

Acceptance criteria

• Define aggregate network units and windows: bit rate, byte/bit volume, connection-attempt rate, target count and bursts; document replenishment and restart semantics.
• Support operator-defined address-prefix or destination groups and define how DNS aliases map into them; do not assume a prefix proves target ownership.
• Test concurrent runs across addresses, users and executors against a shared controlled target group, including limit reductions and restart policy.
• Keep allocations nonnegative/conservative and preserve existing session ownership; coordinate with the separate allocator conservation implementation.
• Keep account job concurrency and retained upload/queue storage governed by their separate admission limits; reaching one budget must not silently consume or reset another.

Current evidence

unimplemented aggregate policy; source inspection only, no new runtime reproduction. Backlog classification is based on source inspection; this issue does not claim a new runtime reproduction.

• internal/dispatcher/resource/destinations.go: Capacity/usage trees are keyed by destination string.
• internal/dispatcher/resource/destinations.go: CheckCapacity checks only the exact destination.
• internal/executor/debuglet/wasm/hostconn/dialer.go: Allowed names are resolved to IP membership without operator-defined aggregate groups.

Dependencies

• #88 — Replace UUID-cookie login with authenticated user sessions
• #65 — Enforce one operator network policy across every guest transport

Related work

These are integration points, not prerequisites for starting this issue.

• #33 — Include earlier batch items when checking schedule capacity
• #38 — Make Allocate idempotent and bind it to the persisted policy
• #41 — Subtract reserved floors before sharing executor bandwidth
• #42 — Invalidate each cached limit when its capacity or competitors change
• #44 — Propagate changed destination limits to active executors
• #45 — Define allocation behaviour when capacity falls below reserved floors
• #99 — Enforce per-account request and concurrent-work admission quotas

Priority context

Required before accepting untrusted users or advertising the corresponding protected capability; not a blocker for the trusted local TEST alpha.

Validation must use owned local fixtures on supported Linux environments. Record the implementing merge request and relevant test results before closing this issue.

Imported from GitLab issue 65. Originally opened 2026-09-10. Historical GitLab links may require access to the original project.