0.11.0 release planning

[djc]

Blocking issues:

• Transmit directly from connection tasks #1729
• Replace rustls-native-certs with rustls-platform-verifier #1734
• Update rustls to 0.23 and ring to 0.17 #1715
• Fix race condition between 0-RTT and Incoming #1821

We might want to try to push these over the finish line:

• Removed assert to check finalize is called before drop #1703
• Make SendStream::finish synchronous #1840
• feat: use mutable transmits to AsyncUdpSocket::poll_send #1692

[Ralith]

I think #1729 subsumes #1692, since you'll no longer need heap allocation to transform Transmits.

[complexspaces]

I don't know if rustls-native-certs ever supported Android (it seems like it didn't?), but it might be worth adding a small section to the README redirecting to the Android setup section of rustls-platform-verifier now if you anticipate Android users.

[Ralith]

We've had a few of those; good thought.

[gabrik]

is there any ETA for this?

[djc]

There is not -- if your project depends on it, please consider sponsoring.

[gabrik]

I can help on #1715 if needed

[djc]

Sure, if you want to finish up my WIP commit there to get it to compile, addressing the open comments, and do the same thing for the server side, that would be welcome.

[djc]

We should also consider these PRs, which include semver-incompatible changes

• add Connection::send_datagram_wait #1740
• preferred address #1816

And would be nice to include these -- but they don't include semver-incompatible changes, so can go in later:

• Socket rebind: drain old socket #1801
• Accept connections with unrecognized address validation tokens #1790

[djc]

@flub recently discussed some benchmarking results in #1729 (comment) which indicate that there might be a performance regression on main compared to 0.10. @flub would you be able to run something like a bisection to figure out what regressed performance? @lijunwangs do you have a setup for benchmarking changes? Would be good to make sure there are no surprises.

[lijunwangs]

We don’t have solid Quinn performance test tool. But I do confirm that when I applied the main branch based code into a test environments where ~300k pps are going on, I did noticed increased packet processing time measured from the first chunk received until the last chunk is received. We have fixed max packet size about 1232 bytes in our application. And I also noticed increased stream read timeout during that. So we do need to investigate the performance impacts

[flub]

@flub recently discussed some benchmarking results in #1729 (comment) which indicate that there might be a performance regression on main compared to 0.10. @flub would you be able to run something like a bisection to figure out what regressed performance?

Yes, I still intend to do some followup on this. A straight bissection is a bit tricky right now since I can't drive our perf infra from the cli currently but have to go via commits and github actions. But I'll see what we can do.

It may take some time though, do you have any rough dates in mind I should be aware off?

[djc]

Probably a few more days until release, but could perhaps hold it if that helps.

[gretchenfrage]

Probably is important to push through #1821 before release, right? Because it fixes a bug which did not exist in the previous release.

[Ralith]

Yep, that's a blocker.

[flub]

Apologies for taking a while, I've made some attempts at bisecting the performance regression and can't really identify anything reproducible and certain enough. The only path remaining for me is to bisect with porting our entire stack to each commit in the bisection. This is maybe not as much work as I fear, but also I'm entirely out of time to spend on this for now.

The good news for you however is that I can't really observe this in isolation in just Quinn. So it probably is something affecting the way we (ab)use Quinn in our stack, which is something not as concerning for holding up your release.

[djc]

@flub thanks for spending time on this and giving us your feedback!

[0x000C0A71]

Is there an update on this? By the looks of it, everything that blocked this has been resolved.

[djc]

I think the current state is that @Ralith is looking into fixing #1803. Not sure how likely that is to include breaking API changes?

[Ralith]

#1803 should be completely invisible to the public API, so it doesn't need to block. I do think I can wrap it up this week, though, so it might be nice to snag it anyway. No strong opinion.

[djc]

• Published quinn-udp v0.5.0 at registry crates-io
• Published quinn-proto v0.11.0 at registry crates-io
• Published quinn v0.11.0 at registry crates-io
• Pushed a 0.11.0 tag