Nick Banks
Nick Banks
I can understand this might be an unwelcome burden for those who do own QUIC and HTTP/3 and HTTP/3 is their primary (only?) protocol. Though, in my experience so far...
I totally agree that a QUIC perf, by itself doesn't convey real-world metrics. That's always going to require the full-up scenario and HW configuration to be tested. My goal with...
FYI, it's a WIP, but I have started a doc for my proposed QUIC perf protocol [here](https://github.com/nibanks/quic-perf/blob/master/draft-banks-quic-performance.md). Feel free to direct any specific questions there. I am trying to finish...
@Winters123 feel free to send a PR for any changes you think should be made. I'd be happy to work with you on them. BTW, I just merged a PR...
IMO, all measurements should be from the client perspective. Additionally, you should always run the tests multiple times and take an mean or median of the results.
I only caution that at msquic release branches only reference xdp release branches.
Many of these problems are why we had decided to always have official MsQuic branches referenced official releases of XDP. I still feel pretty strongly that should stay the case....
See https://github.com/quicwg/multipath. We will eventually support this.
GitHub creates those sources by default. I don't know if there is a way to configure them to grab submodules.
NuGet was automated. Rust crate is documented. What else is there?