feat: add event and function to wait for resumption tickets #2257

Frando · 2025-05-30T08:44:07Z

This adds a new connection event to quinn-proto: ResumptionEnabled. This event is emitted if TLS13 resumption tickets were received. The event is emitted at most once and only on the client side.

In quinn, this adds a new function resumption_tickets_received, which returns a future that completes once the connection received TLS resumption tickets. The future will be pending forever on the server side. On the client side, it will complete immediately if tickets were already received, or complete once tickets are received, or stay pending forever if the server does not send us tickets.

This new feature is useful when doing many short-lived 0rtt connections: It may happen easily that the application-level data exchange is done in a single roundtrip (eg when doing a single, small request-response) but the resumption tickets from the server are only sent in the next packet. If closing the connection after the application data exchange completes, we did not yet receive the new tickets and thus cannot issue further 0rtt connections when our initial tickets are consumed. With this new API, a client-side 0rtt connection can wait for conn.resumption_tickets_received() before closing the connection (should also apply a timeout in case the server does not send any tickets). Thus, it can issue further 0rtt connections without having to go back to 1rtt inbetween.

The PR uses the functionality added in this rustls PR to expose the number of TLS13 resumption tickets that were received so far.

quinn-proto/src/connection/mod.rs

quinn-proto/src/crypto.rs

quinn/src/connection.rs

djc · 2025-06-02T10:49:47Z

quinn-proto/src/connection/mod.rs

+    /// One or more TLS session resumption tickets have been received
+    ///
+    /// This event is only emitted on the client, and is emitted at most once per connection.
+    ResumptionTicketsReceived,


This seems sort of specific to the TLS implementation -- our crypto traits are intended to be more general than that. Maybe this should be renamed to ResumptionEnabled?

Also, note that Event is not non_exhaustive, so this constitutes a semver-incompatible change. In general, this feels fairly invasive for what seems like a somewhat niche feature. Maybe there is some other way to structure this?

I'll rename the event 👍

As to other ways to forward the info: I see these options:

Keep the event, wait until next major release

Add a public getter on proto::Connection for resumption_received or such, and check that in quinn's connection driver poll

WDTY - Should I keep the new event, or add a getter that is checked on each poll? Or did you have something else in mind for how to forward the event from quinn-proto to quinn?

Would like to hear what @Ralith thinks. Personally I still think an event does not make sense for this.

For Quinn to provide an async API, polling would need to happen on the critical path to trigger a Notify or similar, which strikes me as almost as invasive. An event is more plumbing, but doesn't add a branch that gets checked on every poll forever. If we're going to have this, I lean slightly towards an event, but I don't feel very strongly.

djc · 2025-06-02T10:51:01Z

quinn-proto/src/crypto.rs

+    /// Returns the number of TLS1.3 session resumption tickets that were received
+    ///
+    /// Returns `None` on the server side.
+    fn resumption_tickets_received(&self) -> Option<u32>;


djc · 2025-08-12T10:18:21Z

@Frando want to continue with this?

Frando · 2025-08-12T17:39:24Z

@Frando want to continue with this?

Sure. It's ready from my side. There were open question and a request for further review which I can't seem to address myself.

I'm on vacation for the next two weeks, will rebase afterwards.

Frando · 2025-08-28T09:06:26Z

I rebased, removed the patch for rustls (the upstream change was released) and renamed the event to ResumptionEnabled as suggested by @djc.

From my side the PR is ready. @djc wanted @Ralith's opinion on the question whether this should be an event at all. To me an event seems fine for this. The only alternative would be, I think, to check for a field on quinn_proto::Connection on each poll of the quinn::ConnectionDriver::poll. IMO an event is the cleaner way than a check on each poll. However, if the latter is preferred I can change it of course.

This adds a new connection event to quinn-proto: ResumptionEnabled. This event is emitted if TLS13 resumption tickets were received. The event is emitted at most once and only on the client side. In quinn, this adds a new function resumption_tickets_received, which returns a future that completes once the connection received TLS resumption tickets. The future will be pending forever on the server side. On the client side, it will complete immediately if tickets were already received, or complete once tickets are received, or stay pending forever if the server does not send us tickets. This new feature is useful when doing many short-lived 0rtt connections: It may happen easily that the application-level data exchange is done in a single roundtrip (eg when doing a single, small request-response) but the resumption tickets from the server are only sent in the next packet. If closing the connection after the application data exchange completes, we did not yet receive the new tickets and thus cannot issue further 0rtt connections when our initial tickets are consumed. With this new API, a client-side 0rtt connection can wait for conn.resumption_tickets_received() before closing the connection (should also apply a timeout in case the server does not send any tickets). Thus, it can issue further 0rtt connections without having to go back to 1rtt inbetween.

Ralith

No strong feeling on event vs. polling, and it's an implementation detail we can easily change.

Ralith · 2025-08-30T16:22:16Z

quinn-proto/src/connection/mod.rs

            }
        }

+        if !self.resumption_tickets_received && self.crypto.resumption_tickets_received() > Some(0)


Is the number of tickets received guaranteed to change at most once in the lifetime of a connection? If not, should we raise an event every time it changes?

Ralith · 2025-08-30T16:23:13Z

quinn-proto/src/crypto.rs

+    /// Returns the number of TLS1.3 session resumption tickets that were received
+    ///
+    /// Returns `None` on the server side.
+    fn resumption_tickets_received(&self) -> Option<u32>;


Providing a default impl returning None would reduce churn for this niche use case.

Ralith · 2025-08-30T16:27:28Z

quinn/src/tests.rs

+    let endpoint = endpoint();
+
+    let endpoint2 = endpoint.clone();
+    tokio::spawn(async move {


Do we need to join this at the end of the test to ensure any panics are surfaced?

Ralith · 2025-08-30T16:32:12Z

quinn/src/connection.rs

+    ///
+    /// This should only be used on the client side. On the server side, it will
+    /// always resolve immediately and yield `false`.
+    pub fn resumption_tickets_received(&self) -> impl Future<Output = bool> + Send + 'static {


Is anyone going to ever inspect this bool? Seems redundant to checking side().

Ralith · 2025-08-30T16:34:58Z

quinn/src/connection.rs

+    ///
+    /// This should only be used on the client side. On the server side, it will
+    /// always resolve immediately and yield `false`.
+    pub fn resumption_tickets_received(&self) -> impl Future<Output = bool> + Send + 'static {


How is the user meant to actually get the ticket? If the expectation is that they'll still be going through rustls's ClientSessionStore, would it be simpler to bypass quinn entirely and use a ClientSessionStore that notifies you directly on insert?

This comment was marked as outdated.

Sign in to view

flub reviewed Jun 2, 2025

View reviewed changes

Frando force-pushed the feat/ticket-recv-event branch from 139c2c3 to d9102bc Compare June 2, 2025 09:44

Frando marked this pull request as ready for review June 2, 2025 09:47

Frando requested review from Ralith, djc and gretchenfrage as code owners June 2, 2025 09:47

Frando force-pushed the feat/ticket-recv-event branch from 0042ae9 to 7f9c190 Compare June 2, 2025 10:11

djc reviewed Jun 2, 2025

View reviewed changes

Frando force-pushed the feat/ticket-recv-event branch 5 times, most recently from b675e2f to a202b28 Compare August 28, 2025 09:02

Frando force-pushed the feat/ticket-recv-event branch from a202b28 to 5620185 Compare August 28, 2025 09:34

Ralith reviewed Aug 30, 2025

View reviewed changes

Uh oh!

feat: add event and function to wait for resumption tickets #2257

Are you sure you want to change the base?

feat: add event and function to wait for resumption tickets #2257

Uh oh!

Conversation

Frando commented May 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

djc commented Aug 12, 2025

Uh oh!

Frando commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Frando commented Aug 28, 2025

Uh oh!

Ralith left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Frando commented May 30, 2025 •

edited

Loading

Frando commented Aug 12, 2025 •

edited

Loading