QUIC 0-RTT connection resumption from disk

[Sebastian Lobo]

Hi team,

Purpose: Be able to implement QUIC 0-RTT connection resumption from disk as a /net library client as a latency optimization

Context: We are currently using the /net library for http requests over QUIC. We've instrumented and have observed a significant (for us) latency bottleneck in the QUIC handshake on application boot. We are hoping to optimize this away by persisting the necessary state for 0-RTT on disk for ~24 hrs, and loading this state from disk on the next run.

Questions:

1. Is there an example or exposed API to do this today?

• In an ideal world, there'd be a utility analogous to net::HostCache::PersistenceDelegate that library clients could implement to serialize relevant QUIC handshake state
• Note: we are currently using /net (as opposed to cronet), and quiche to make these requests. If there is another library or QUIC implementation that would make this easier, we'd be very open to it.

2. If there is no exposed API to do this today, can I find someone to provide counsel and review on proposed design, and ultimately reviews on change lists?

• This is high priority for us and we are happy to roll our sleeves up as much as necessary, but I want to make sure to have support from /net reviewers for such a proposal.

Thanks for your help,

Sebastian

[Nick Harper]

To support this, https://source.chromium.org/chromium/chromium/src/+/master:net/quic/quic_client_session_cache.h would need to be modified to persist its cache to disk.

However, I do not think there will be any support from the Chromium project to make such modifications to the network stack.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/ad15050a-7b92-4437-9d6e-a7709c8c006dn%40chromium.org.

[Ryan Sleevi]

As Nick mentioned, this is probably not something that would be useful for upstream. We previously explored, and ultimately rejected, doing the same with things like TLS session caches, as well as certificate verification caches, on both mobile and desktop, and consistently found it has degraded performance (network is faster) and security.

Have you measured into the latency bottleneck? And on what platforms you're looking at? For example, Android has known performance issues for application first launch due to how certificate verification is handled by the system, and similar issues exist on other platforms (where the root store has to be loaded/consulted and is generally a cold cache on an apps first start)

Before going too far into the specific solution, it might be useful to frame the performance gaps using detailed traces and investigations, because the odds of wanting to introduce such a footgun upstream seem low.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAFvk8pxemCDRkVcFqFdVHRQ4WuBDw%3Da_Ff%3DPUwEo5%2B3U1pHnLg%40mail.gmail.com.

[Sebastian Lobo]

Thanks Nick and Ryan for your input. 

Per Ryan's point, we'll be conducting a few more detailed benchmarks on the exact function calls that are driving the bottleneck, and see if this is related to the mentioned Android known performance issues at application first launch. This should help with determining next steps.

Best,

Sebastian

[Berte Colin]

Hi,  all:

 Is QUIC 0-RTT specific to QUIC-TLS 0-RTT？ Cause as I know QUIC-CRYPTO supports 0-RTT resumption from disk when HTTP_CACHE_DISK mode is enabled in Cronet.

Best,
Colin