JoTurk

Both Claude and Codex refused to help verify, triage, or develop proof-of-concept reproductions for any of the issues reported by oss-scanner. This was counterproductive, as we were trying to fix the vulnerabilities and coordinate CVE disclosures as quickly as possible. We already had detailed vulnerability reports from Anthropic, so refusing to help us validate and fix those same issues made no sense at all!

I'm not sure if it's a user issue, but someone sent me a long markdown of issues GLM 5.3 found, and most of them are panics (we don't consider panics to be CVEs) It didn't find any of the CVEs oss-scanner found.

We don't have access to much AI tools our-self since Pion is free and opensource and we don't get paid :) so we rely on token donations for review and fixes

Okay, I see your point, but our test harness isn't meant to be an absolute "max throughput" benchmark. every packet is parsed, corrected (if needed), and validated in real time (CRC32c, on-the-wire checks, deterministic network emulation, etc.).

If we ever want a true ceiling number, we could add a separate fast path (e.g, a dump-writer / sink that skips most validation) or validate after run, but that's not in scope right now. our scope was: (1) validate Pion/SCTP PRs and (2) compare performance against other branches and version. so for relative benchmark under identical conditions.

on head-of-line blocking: we have a pending RFC 8260 message interleaving (I-DATA) implementation, and we've tested with it; it helps reduce HoL on the sender side (especially around fragmentation). our benchmark tool has a flag to run with interleaving, and we tested it quit a bit. We plan to release it in Jan.

SCTP isn't just a UDP pipe, It's a message oriented, congestion-controlled, reliability protocol, with bunch of other semantics.

We measured:

1. Association state + Per PATH CC/RTO, timers, RTT tracking, cwnd etc.

2. Selective ACKs and re-transmit logic.

3. chunk framing + tsn sequences.

4. ordered vs unordered delivery, and fragmentation/reassembly.

much more ...

Also our vnet-based implementation isn't just dumb buffer, we have packet on wire validation, SCTP parsing, CRC32c validations. deterministic network conditions emulator. With real time conditions.

Sure you can get 100 GB/Core second if you bypass all of that and just do huge batching

The blog post claim is just under the same SCTP semantics and the same test harness, enabling RACK has a huge win. not the absolute ceilings of in-process "virtual network" sockets :)