Skip to content

chore(quest): plan the MoQ QUIC packet path investigation - #385

Merged
kixelated merged 1 commit into
mainfrom
quest-plan/moq-quic-path
Nov 5, 2026
Merged

kixelated merged 1 commit into
mainfrom
quest-plan/moq-quic-path

Conversation

@kixelated

Copy link
Copy Markdown
Collaborator

Problem

zshenker's independent Zen 2 numbers on moq-dev/moq#7873 show rind 0.1.12 already ahead of aws-lc-rs on MoQ's QUIC path. Nothing plans what would make that path faster still, in rind, in rind-rustls, or in moq-quic's call path. Since then, 0.1.13 also moved Zen 2 and 3 onto Vale's AES-GCM, which was slower at small sizes.

Approach

Adds quest/m1/moq/quic-path.md [M] under the MoQ epic. It re-measures, profiles moq-quic's packet path, and writes up each gap for the maintainer to approve as its own quest, in rind or in moq-dev/moq's perf epic.

Impact

None on the public API. Quest files only.

Decisions

Settled with the maintainer on 2026-11-05 through /quest-plan:

  1. Scope:
    • rind and rind-rustls, plus moq-quic changes ✅
    • rind's primitives only
    • rind and rind-rustls only
  2. CPUs:
    • relay servers first, then clients ✅
    • every tier equally
    • x86_64 only
  3. Milestone:
    • m1 ✅
    • the m2 speed epic
  4. Structure:
    • one rind investigation, with fixes planned in each repo ✅
    • an investigation in each repo
  5. New public QUIC API in rind:
    • allowed if it measures a clear end-to-end win ✅
    • none
  6. Bulk encryption: performance beats verification, so the fastest source wins even within the ~10% rule's margin (maintainer's direction).

Review

Skipped as a quest-only plan.

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@pullfrog

pullfrog Bot commented Nov 5, 2026 •

Copy link
Copy Markdown

Your OpenCode Go account is out of credit. Top it up, then re-trigger Pullfrog.

OpenCode Go's response
provider error: Upstream request failed: Insufficient account funds

Top up OpenCode Go →

Pullfrog  | Rerun failed job ➔ | View workflow run | via Pullfrog | Using glm-5.3

@coderabbitai

coderabbitai Bot commented Nov 5, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 14 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: e90f67f2-96c7-4d50-8a3f-f997f227e187
Commits

Reviewing files that changed from the base of the PR and between e69a6a1 and b5c8837.

Files selected for processing: 2

  • quest/m1/moq/README.md
  • quest/m1/moq/quic-path.md
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

@kixelated kixelated left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated review by review (OpenAI)

Reviewed head: b5c8837

Two factual corrections in quest/m1/moq/quic-path.md:22:

  • [P2] Keep Zen 3 out of the native Vale tier. The repository's Zen 3 CPUID fixture has VAES and VPCLMULQDQ, and GhashTable::new selects VaesAvx2 before Vale. Normal Zen 3 therefore did not move to Vale in 0.1.13. Remove Zen 3 from this example, and distinguish native runs from runs with VAES deliberately disabled; otherwise a Zen 3 before/after result can be attributed to a backend it never used.

  • [P3] Identify the 6–11% comparison as a rind regression. #329's 32 B numbers are previous rind → Vale rind on an i7-8700 (44.4 → 49.4 ns and 50.5 → 53.7 ns), not a comparison with aws-lc-rs. The old rind path used the by-8 code at 32 B; its aws-lc AVX seal kernel started at 288 B. Say “6–11% slower than the previous rind implementation on Coffee Lake” so this does not become evidence of an aws-lc-rs gap or a measured Zen 2 regression.

Direction: the investigation-first scope, separate follow-up quests, and end-to-end measurement gate are sensible. Correct the baseline before using it to choose implementations.

Verification: GitHub-only static review of both changed documents, the cited benchmark report, relevant dispatch/adapter code, and existing QUIC tests. No code or tests change here; I did not execute tests, quest context, or benchmarks. Queue checks were skipped; Pullfrog failed from exhausted credit and CodeRabbit was rate-limited, so neither is a passing validation signal.

Merged via the queue into main with commit 5a427d0 Nov 5, 2026
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant