 I'm one of the Envoy senior maintainers. I've been working on the Envoy project data plane for ages now. In the last two years, I've been focused on upstream enhancements largely targeted towards Envoy mobile. So I'm leading the team at Google, a unified client network team that's been working heavily with JP and the folks over at Lyft, getting Envoy mobile up and working. So when we joined this project, it was kind of clear to me that the Envoy network stack really had been written for use in data centers. So you had things like having to hard code your upstream protocol, right? And in your data center, you know if your endpoints are speaking HB1 or HB2. But when you're working on the open internet, that's generally not how things work. Also, you roughly had to hard code the address family. So we did have things like v4 and v6 preferred, but essentially Envoy would resolve one address and try to use it. And again, on mobile networks, if that address family wasn't supported, you're out of luck. You didn't have connectivity. This is obviously suboptimal for Envoy mobile, but this also isn't great. Again, the Envoy mobile upstream code is the same code that Envoy uses. So if you're using Envoy as a dynamic forward proxy, say as an egress gateway, you may have these same problems. And the fixes that we did work both for upstream Envoy with dynamic forward proxy, as well as Envoy mobile. The first thing we did is add ALPN support. And that basically gives you, we added a new upstream configuration that lets you negotiate whether you use H2B2 or H2B1 as part of the TLS handshake. So there's no latency penalty, right? This has done inline a couple extra bytes on the wire, and it'll automatically use the best available protocol. If you're talking to an older endpoint on the internet that doesn't support ALPN, it just fails over to using H2B11. So again, you're pretty much guaranteed to get your traffic through. Envoy defaults to assuming your endpoint is going to use H2B2. So what does this mean? If you're starting on your Envoy with a cold start, it hasn't talked to this endpoint ever before, and you have a flux of incoming requests, it will try to establish one TCP connection, assuming that those various streams can be served over one connection. However, we didn't want a latency penalty if that endpoint supported H2B1, right? Where you could only serve one request and one connection at a time. So we added what we call this alternate service cache. And the alt service cache is that protocol. So subsequent streams as they come in, will remember that H2B11 was used and prefetch one connection per incoming request. This alt service cache is cluster local by default. So again, if you're a cloud provider and you don't want information shared between different customer clusters, it's completely isolated. But if you're running this in-house and you want to share this information so that if you have, for some reason, two dynamic forward proxy clusters and you want to not have to look these up every time on cold start, you can really easily configure different clusters to share this cache. For config, it's pretty simple. So if you're using modern Envoy cluster configuration, you'd have a section explaining your H2B protocol options and you would have had something like explicit H2B config, here's my H2 config. You just replace that with auto-config, that's it. Optionally, again, you can add in this alternate protocol cache if you want to share caches across different clusters. The next thing we added was H2B3 support. As Matt mentioned, this was one of the features that we're most excited for Envoy having going forward. And while Envoy has been able to terminate H2B3, speaking H2B3 upstream is a little bit different. So we added two modes here. One is explicit H2B3. This is for in-data center use when you know that UDP 443 or whatever port you configure is going to work. On the internet, that's not a good idea to use. So we added auto-H2B3 support so that if your ISP that you're on is blocking UDP 443, right, then Envoy will just do the right thing. So explicit H2B3 will just fail if UDP's black hole, but it will guarantee that you use H3 and you don't have to look at your stats and metrics to make sure it's being used. When you're on the internet, auto-H2B3 relies on the standards alternate service header. So it won't use H2B3 unless your endpoint advertises that supports it, because at this point, it is not the case that most servers on the internet do. However, if H3 is advertised, Envoy will try to use it. But it will also attempt TCP after a short timeout. So again, if your ISP is blocking it, if you're behind a corporate firewall or something else, you'll end up using whichever connection is established more quickly for the best available latency. Shortly after we added H2B3 support, we added support for zero-run Japanshakes. This is one of the signature features of H2B3. Basically, if you've communicated with an endpoint before, you cache your credentials. And then the next time you talk to that endpoint, you send those credentials and then it can immediately start sending get-and-head requests without waiting for a TCP handshake or a TLS handshake. So this is awesome for latency. It'll be used by default for safe methods. But again, if for some reason you don't want to use it, you can turn it off via a per-route early data policy configuration. So hard-coded H3 config, it's as simple as taking your H2 config, crossing up the two and adding three. There is one other difference elsewhere in your cluster config though, because we basically have to repair the crypto to do H2B3 logic. Instead of wrapping your crypto config in a TLS transport socket, like you would have normally done for encryption, you wrap it in a quick transport socket. But if you look at these two yellow boxes, you're literally just copy-pasting the config you had into a different wrapper proto. So it is a pretty easy transition. For auto-config, again it looks a lot like auto-config for H2B2. You just say your H3B3 protocol options, but again, this time you have to include your alternate protocols cache. It's required because Envoy won't work without it. It won't remember that that endpoint's important H2B3. So we just fail config on startup so you can't make that mistake. Same thing in your filter chain, you can figure that service cache. So as you get response headers, we insert again into that cache so that Envoy will remember what protocol was used. The last school feature we added was happy eyeballs. So happy eyeballs is the de facto way to use IPv6 on the internet. It basically attempts connections to preferred address families while trying connection both to IPv4 and IPv6. So from my desktop, I did a DNS like EverGoogle.com. I got a v6 address and a v4 address. The implementation will try the v6 first and then if no connection's established, again my ISP's blocking it for some reason. After a 300 millisecond pause, we'll attempt a connection to IPv4. And again, this is fantastic. It resolved a lot of issues on various carriers and networks where you get to resolve both addresses that are only one of the works and it's a surprise as to which one will. And then again, to use this, all you do is configure Envoy to use DNS lookup family all. So it'll resolve not just one but often multiple v4 and v6 addresses. So also when you're migrating across networks and whatnot, it can be very helpful to try different endpoints because again, the route to one of them may be blocked. Happy eyeballs configuration again, super easy. Where you would have your DNS lookup family for like v4 only or v4 preferred, you just stick in all. And then all of the logic is done under the hood for you. In conclusion, we've added a bunch of new really powerful features to Envoy and we've done our best to make sure that they have very simple configuration. I wanna call out that the team that did all this work is a team that launched HB3 for Google. So we have years and years of experience tuning HB3, tuning timeouts, tuning these failovers to be optimal for both Google's web search which we really deeply care about. And it's very, very latency sensitive along with YouTube, right? This long haul streaming type traffic and making sure that we have kind of optimal throughput and bandwidth and quality of experience for both kind of your fast traffic and your long haul traffic. So we have really high confidence that kind of the default configuration is going to work well on almost all networks and almost all conditions. And again, we have knobs. So if you're in some weird special corner case, you can tweak it accordingly. As usual, there's a bunch of examples of this and documentation on Envoy ProxyIO. And if you have questions or concerns we didn't get to today, we're all on Slack. So feel free to pick us. Do we have any questions? Yeah, yeah, so we've got a list of other things. Envoy, what we don't yet support and we want to is connection migration for HB3. So essentially, JP mentioned earlier on that, especially for Lyft, they're doing a lot of like walking out of houses or buildings and you're switching from Wi-Fi. So we've had good luck in Google for actually migrating those connections, like from your Wi-Fi to your cellular interface. We haven't yet done that plumbing for Envoy Mobile and it is on our roadmap. The other one we want to do is better handling for HB11. It hasn't been a high priority for us or Lyft because we all use H2 and H3. But it is really important to handle legacy cases on the internet. And so there's things that kind of best in practice for network stack, like when you get one request to give an endpoint and you know you're using HB1, it makes sense to prefetch a number where you can hard code that number of connections. So like browsers, if you talk to Google.com will immediately establish six connections because if you have one request you're likely to have more following on. So there are a couple things like that and we've got a list of improvements that we're hoping to do in Q4 and then going forward. Any other questions? Cool, I'll end off to the next speaker.