Session Date/Time: 20 Jul 2026 12:00
[00:00:04] Tommy Pauly: Yes.
[00:02:26] Eric Kinnear: We've got a very full agenda today, so let's get started. Welcome to the happy meeting at IETF 116. There was a QR code up here until it was replaced by this thing. So if you haven't joined in MeetEco yet, there's a link from the agenda. There's a QR code at the back of the room. There's QR codes usually stuck to the microphones. So please make sure that you hop in and join the MeetEco. And this session is being recorded as usual. When you're in MeetEcho, you can join the queue with the hand button, same as it's been for the last couple of meetings. If you're in person, you still need to join the queue and then you should line up at the mic line and we'll call on folks in the order that they join that queue. This is the note well. These are the terms under which we participate in the IETF. Please make sure that you've read it. This is Monday, so you haven't read it that many times this week yet. So please make sure that you've read it. Take special note of the responsibilities that are placed upon you in regards to IPR. And also a brief reminder that we operate with a code of conduct. So if you observe any violations of that code of conduct, you can reach out to the chairs, the ADs, the ombuds team, and they'll assist you with that.
[00:03:45] Andrew Alston: Thanks, Andre.
[00:03:47] Eric Kinnear: We got some helpful links for the PDF. And this is our very full agenda for today. So we've got a bunch of stuff to talk about. We're gonna talk about the main document. We've got implementation updates from three major browsers. And then we've got some conversations about web tester stuff and then some error reporting. So with that, let's get started with our first talk.
[00:04:10] Andrew Alston: Or do we need a note to take notes?
[00:04:12] Eric Kinnear: Good point. Would anybody like to volunteer to take notes? In this AI assisted age, it is less of a burden than it used to be.
[00:04:23] Andrew Campling: Do we have AI tools?
[00:04:25] Eric Kinnear: There are some unofficial ones that are taking the recording of the session and the transcript and stuff. So it really is legitimately just major decisions now as opposed to like try to actually scribe everything. I see a hand from Brian. Thank you, Brian. Okay. And then we should have a clicker.
[00:04:52] Tommy Pauly: The pink press is control. Does this work? It's a good question.
[00:05:02] Eric Kinnear: Well, maybe it needs to plugged the alright. You can just hit next slide. That works too.
[00:05:13] Jordi Palet: It should be put into one of these.
[00:05:18] Gautam Tenneti: Sorry. I won't mess with that. Alright.
[00:05:26] Nidhi Pinamaneni: Okay. Hi, everyone. I'm Nidhi, and we'll be talking about Happy Eyeballs v three. Next slide. So we'll start with some of the updates for the latest version of the draft, and then we'll go through some of the open issues.
[00:05:43] Mirja Kühlewind: Next slide.
[00:05:45] Nidhi Pinamaneni: So here's an overview of the changes that we've made to the latest version of the draft since the last meeting. You'll notice some of the PRs were just editorial. We changed mentions of address to endpoint where it was appropriate and the draft to be more consistent with language. And then the second one was replacing the word interface with PVD since it's more accurate. Next slide. This was an issue that was raised earlier as well. We had previously added some text where we said these issues might be specific to IPv6 traffic, but it still wasn't quite clear. So, we've now added some more text to say that this is due to the IPv6 header that can be larger than the IPv4 header. Next slide. And then, we've also added a lot of examples for the DNS answer processing, as well, of what are the different situations that might happen of what answers we get, and then how do we react to that in the algorithm. So, one example is if we get the HPS and Cloud A record, we can start the IPv6 attempt right away. And then when we get the A response, we can start interleaving the IPv4 and IPv6 addresses and then continue on with the race. And then the second example is if we get HPS and a but don't get the quad a, we start the resolution delay timer. And then when we get the quad a after ten milliseconds, we'll start the race with both I p I p v six and I p v four. Next slide. Yeah. I think that's the major updates. Tommy, do you wanna talk?
[00:07:32] Eric Kinnear: Ben, is that a now question or a later question?
[00:07:37] Ben Schwartz: Hi. I I just saw something go by that the concerns about I p v six are due to increased I p v six header size. That doesn't sound accurate to me. I really would have expected that the answer is due to different fragmentation handling. So maybe somebody who is familiar with fragmentation issues should take a close look at that and make sure that we're describing that situation correctly.
[00:08:06] Eric Kinnear: Sounds good. I think we'd had a long hallway conversation at one point with Corey about some of this, but we can circle back and make sure that loop gets closed.
[00:08:17] Tommy Pauly: Okay. Sounds good. Alright. I'll talk through some of the open pull requests here. So if we can go to the next slide. Or do I have a clicker?
[00:08:26] Eric Kinnear: This is not working, but if you have your phone, you can do click with that.
[00:08:30] Tommy Pauly: Sure. Up to you. Request lines.
[00:08:40] Eric Kinnear: You have to request them fully. Right? Hang on.
[00:08:43] Tommy Pauly: I can just transfer to you. Okay. So the major thing that we've been discussing for a while now is updating the I p v six only network handling guidance. This is an area of text that we had a lot of original guidance around in Happy Eyeballs v two. That was in an age before we had the PREF64 option, and
[00:09:12] Speaker 9: all we
[00:09:13] Tommy Pauly: had was, like, oh, this new DNS six four, NAT six four thing. We had done some updates, but we'd realized, like, the guidance was not fully complete. So last meeting at IETF 115, we had a call, with a number of people, and we discussed briefly, in the working group session as well what the proposal would be. I've taken a stab at turning that into text, and so this is PR number 137 on the dock. So a lot of this is please review and help get this merged in so we can finally resolve a whole slew of open issues around v six only network handling. So that's what we're trying to do. So just to briefly summarize the changes that I'm making in this PR. So first, there is a set of changes that's not down in what used to be the section around I p v six only networks, but it's up at the beginning for the rules for sending queries. And so this is section 4.1. This is kinda like the first stage of happy eyeballs of, like, what do you even send? And so it's simplifying things to say that, okay. Overall, if you're deciding between a, quad a, sending, it's about the routes that you have within your PVD. Your PVD is the provisioning domain, so it's the set of coherent network information for the interface DNS resolver, etcetera, that you have. So if you have global v four connectivity, you send an a query. If you have global v six connectivity, you send a quad a query. And then also, if you are aware of a NAT six four prefix in any way that you're aware of it, you must also send an a query. And so this is, different than what happy eyeballs v two had, but this is what we've been talking about for a while in here. So then there's the lower section that goes into detail about well, so this previously was called, like, the I p v six only and I p v six mostly networks. And I've renamed it to just be about how to handle NAT six four because that's really all it comes down to. And here, you essentially can discover, are you on a network that has a NAT six four prefix that has prefix four? You can either discover that from the RA option, or you can discover it by doing the query for ipv4only.arpa. And all of the the rest of the logic comes if you do find that prefix. So if you cannot discover that, then you ignore everything else. You just kind of carry on as if you have true v six only or normal dual stack. So if you do find the prefix, you must send the a query, as I mentioned before. And if you ever have I p v four literals that were added, like, that you're trying to directly connect to or that you learn about through I p v four hints in the SVCB records, etcetera, you synthesize those. And you must treat the synthesized addresses, including anything you get back from d n s six four that you realize has been synthesized as a v four address for the purpose of the happy eyeballs sorting and grouping and everything else. So you you rank it as if it is v four address because it's not native v six all the way, but this is all you need to do for this basic case. So that's what the PR currently does. It also as we noted in some of the discussion, it eliminates one of the configurable values that we used to have overall, which was this last resort local synthesis delay, which is a mouthful, and so we can get rid of it. That's great. So this was a timer that used to be around to say, should I send an a query on this v six only network because maybe something's busted otherwise? We don't need that because now we're always gonna send the a query. So great. The other thing that I think based on the discussion we are having on the PR that we need to do is address the split tunnel VPN case. This is something that did have text in there before. I had deleted it as part of this PR because I think a lot of that was outdated, but I think we do need to bring back something there. This is a case where, potentially, you have received a DNS answer that maybe a synthesized v six address from a v four address, and that v four address really belongs to a split tunnel VPN configuration where you would natively use v four. So I think we need some text around that. I'm happy to hear suggestions on ways that you think that could be phrased. But I believe other than that, this captures what we had discussed last meeting. So happy to hear comments. Eric.
[00:14:41] Eric Nygren: On the VPN tunnel topic, I was just doing a full read through of it earlier today. And one thing that did jump out to me is I think the call the kind of section the topics around PVDs and VPNs probably wanna and network connectivity probably wanna get pulled up to a top level section because I think there's a number of these things that got interwoven throughout on things like when you when you need to flush your DNS cache on network changes and get a pulling that up out of this section to a top level thing would make would probably make more sense and make it more readable.
[00:15:10] Tommy Pauly: Got it. Thank you. It's a good idea. Jen.
[00:15:14] Jen Linkova: Yeah. Jen. So I think I might create some confusion in the PR, particularly because I am looking at the slides from the last meeting, and it's and I think on those slides in section of what we're gonna do with what the answer is not exactly what on your slides right now and not on the PR. So we might need to maybe sit down and rethink it again because I think the idea and even my example, which was on the slides last time, right, gives you different results. So, like, I I think that we did discuss unsynthesizing at least last time. Right? So I maybe what you're proposing is a better way. Right? I'm just thinking about we need to talk about, yeah, how to solve VPN case with that approach. Right? Because another suggestion I actually like Lauren's suggestion from one of the previous meetings that maybe we don't need to think about all of it and just let default address selection to deal with that.
[00:16:17] Tommy Pauly: Right. So I I I guess I would be curious, and may if you can do it now or if you can do it on the PR to unpack, like, what are the the the meaningful differences? Because I think, you know, I I acknowledge that, like, you know, what we had previously from the notes for the side meeting is, like, yeah, slightly different. But as I tried to turn those into the actual guidance, that's how we got to the PR. So I think specifically for the unsynthesizing bit, like, there's there's the bit about, you know, treating the synthesized addresses as v four addresses. So you could say that anytime you have a synthesized v six address that you get from DNS six four or whatever else, You first desynthesize it into v four. You run it through everything as v four. And then at the last minute before you actually use it to connect to anything on this PVD, you resynthesize it back into v six. I think that's morally equivalent to just saying I have it as a v six address. I I know what the inner v four is, and I treat it like v four, but I don't actually have to literally, in the code, unsynthesize it, and then resynthesize it. Like, that's more of an implementation detail to achieve the end K. I think.
[00:17:39] Jen Linkova: Yes. I think I think that idea was that if you have synthesized v six and you have v four, we want to make sure that the traffic will be sent as v four. So if you have or if you have more specific routes for that v four, right, it will be treated as v four, not for the purpose of sorting, but for the purpose of sending traffic. And it will solve VPN case. Right? But I guess, yeah, we'll need to talk about it a bit more maybe in the PR.
[00:18:10] Philip Tiesel: Okay. Philip Tiesel. I already commented on the PR that I think the VPN case will more or less be the same issue or the same discussion as a PVD. So it's I would just say VPN is nothing like an implicit PVD that defined itself by the VPN configuration. But I think if if if we think about the cases, what could go wrong? So you could use DNS sensors from a wrong resolver that's solved by treating as a different PVD. If we now have an IP v six v four address, we only could resolve through that VPN. We already have resolved it through the PVD and would use it in the context of the PVD and would use the root of that PVD. So in the end, I would argue that if we get PVDs right, we also cover all the stuff for VPN.
[00:19:12] Tommy Pauly: So I I think that aligns well with what Eric Nygren was saying for kind of pull it up into a broader section there. So so the one of the questions I would have here, because I think where it can get a bit messy, is that if you come from, like, a pure like, a purest PVD standpoint, you would say, like, I don't ever use answers from one PVD on a different PVD. Right? But I am aware of split tunnel VPN like cases where you like, the the deployment expects things to resolve in one place but then end up connecting over a different route. Oh. Just because that's how implementations have worked, and there are things that do depend on that. So I think being strict around that will would cause breakages. That's my concern.
[00:20:06] Philip Tiesel: I agree on that, but I think perhaps we have to think about yeah. We have leaky routes and other concepts, so we might think about leaky PVDs that say if you end up the DNS resolution leaking out of that PVD, that's fine. By definition, to care about things like split tunnels. So you do DNS. It's marked as a leaky PVD and say, okay, this DNS answer I'll then use on the default PVD or default route or whatever gets me out of that PVD.
[00:20:47] Lorenzo Colitti: Lorenzo. I think part I think the problem is with when we when we define PVDs, we
[00:20:55] Philip Tiesel: I was in we didn't add
[00:20:58] Lorenzo Colitti: any mechanism to declare the absence of information in the PVD. Like, the PVD can say these things are part of the PVD, there's no way to say this is not part of the PVD. And there's also, like, no easy way to, like, fault in parts of, like, the routing space that are coming from another PVD. Right? I think that the spec really doesn't say that. And so the thing with split tunnels is that, like, you basically sort of the VPN has to abdicate most of its space, it has to come from somewhere else. It's, like, actually very difficult to use PVD to to represent that. So so I think that's that's a bit of a challenge here. Yeah.
[00:21:31] Tommy Pauly: I
[00:21:33] Lorenzo Colitti: I do wonder whether we should fix the PVD stuff, but, you know, that that's doesn't doesn't belong here.
[00:21:41] Tommy Pauly: I guess, would you argue then that we should, kind of like what it did before, just talk about, hey. Split tunnel VPNs are a thing separate from trying to reconcile the whole PVD world? Or I mean,
[00:21:54] Lorenzo Colitti: I think we in this talk, we're I think giving pragmatic guidance is probably the right approach. Right? And, yeah, even if it doesn't match perfectly with the the with the stuff we introduced in PVDs, we we'll we'll have to sort of wing it when saying, because I don't know if, you know, if we read the PVD spec, does a VPN even count as PVDs? Maybe. Right? So Right. So we'll we'll sort of wing it a little bit, but I I do think using PVD as a sort of, like, very clear guidance for, like, physical interfaces is helpful because that's well defined, and it's like, know, guess we should do that. For VPNs, maybe we just have special case case text that says, well, do this even if
[00:22:35] Ben Schwartz: it doesn't quite match with the PVD. Right. Let's see.
[00:22:38] Lorenzo Colitti: K. I mean, I I can't remember the text, but I remember spent I was spending, like, collectively a lot of time on it, and it seemed kind of to do what it needed to do. So maybe we should, like, leave the text there.
[00:22:48] Tommy Pauly: Yep. Okay. Alright. We'll get some more comments and discussion. Jenny will help on that. And then I think we'll add back in some treatment of split tunnel DNS onto this PR, and then please help review so we can get it merged soon. Okay. Good. That was that. Alright. One of the other open PRs is around the selection of DNS server addresses. So this is one where I, again, wanna get input and feedback here. So happy eyeballs v two had this text. This is something that we inherited from that RFC for essentially saying, hey. You know how you you really like v six addresses when you connect? You should also like v six addresses when you do your DNS resolution if you have a choice. So this is about what you use to talk to to pick your DNS resolver itself. There's a draft in DNS op that says some things about DNS server address selection, which is really just deferring to RFC sixty seven twenty four, but it does not talk anything as far as I can tell about preference between the address families. It's just normal sorting. So whatever you had in your original list, whatever was at the top would probably stay at the top for whatever your preferred add whatever the address family was. So this PR just is a slight modification where it points to these documents and then says that you can sort the preferred address family, which is v six, up to the front before running the rest of the sorting and that you penalize nonresponsive DNS server answers, server addresses, and you would switch over to the next if you realize that a particular, result recursive resolver was not being responsive. And this is mimic this is just essentially describing what Apple's mDNSResponder has done for a while, and that's where this came from. So I think there's probably, like, what do we think about this? I think there's some question of, like, does it even still necessary belong in here? It is essentially just applying the happy eyeballs philosophy to this other step of it, but it is a bit separate from the connection establishment logic itself. Lorenzo?
[00:25:24] Lorenzo Colitti: So I don't think it's true that, you know, sixty seven twenty four doesn't have any sorting preference across the rest families. That's what it does. Right? So 6724 will say says something like, well, prefer native IPv6 if you have it, but if you only have a ULE, prefer IPv4. So that that's, like, we're actually very opinionated about v four versus v six, and it it doesn't sort the families one ahead of the other. What it does is it looks at, like, the set of addresses address pairs that you have and then sorts those. And so it it is it de facto a superset of doing something very simple like what you have here. So Okay. What I would say is either we sort of leave this unspecified, right, or we say because I think looking back, I think I might have been the one that made the suggestion of using 6724 for 3913901 bisque. I can't remember what the corner case is that they were trying to solve with that document, but we basically ended up saying, well, if you need to make some decisions on sorting, you might as well make the same decisions to talk to your DNS servers that you would for to talking to any IP address. And so I feel that there's value for for the sorting to be consistent. So either we say nothing or I think we should say sixty seven twenty four bis.
[00:26:37] Tommy Pauly: So I think we we we could just, right, point to these docs and say Yeah. Sixty seven twenty four bis has the effect already of sorting this up if it's appropriate. Yeah. I think it's still useful potentially to discuss, you know, what happens if Oh, penalizing, I think,
[00:26:55] Lorenzo Colitti: is fine. Yeah. Penalizing Keep it penalizing. Yeah. But I think I think in terms of, like Okay. Just like a sort of DNS lookup will give you some set of addresses, and you'll have some set of source addresses. When you do a DNS lookup, you'll have some sort of server addresses, you'll have some set of source addresses. You just do the same sorting there. Okay. And, yeah, penalizing nonresponsive, yeah, that that definitely is is is advisable. Think we should have text about that.
[00:27:17] Tommy Pauly: Great. Okay. So we can update that.
[00:27:20] Andrew Alston: Ben. Ben, go ahead.
[00:27:28] Ben Schwartz: Hi. I just put a a long comment on this PR, like, two minutes ago. But I think the the bottom line for me is I I think that we should try to stay out of this. The DNS connection, like, optimization is really a different problem space from this. And even where it's the same, it it can be structured separately, and I think that's better. It's easier to understand. Put a long comment about what I think is actually need to hear out. I just wanna, repeat here that this is talking about the I p v four and I p v six, but DNS has something like six different specified transport protocols currently.
[00:28:23] Johannes Zirngibl: And
[00:28:23] Ben Schwartz: there's lots of interesting questions about how you choose between them. And I think that that ultimately would be a great place to use Happy Eyeballs, but I don't think that Happy Eyeballs needs to sort of transitively include that into the definition of Happy Eyeballs. So Happy Eyeballs can use DNS. There's a hard abstraction barrier. We don't know what goes on behind the curtain, and then DNS can be a customer of happy eyeballs too.
[00:28:49] Tommy Pauly: Yep. Yep. It's true. Okay. So I think so that that option is just, like, remove all of the discussion of that. So I I guess I I'd like to get a sense from the room of, like, would we prefer to just remove all mention of this, or do we do something like we were discussing just now with Lorenzo of, like, saying, like, yeah. Look at these. Like, look at this other spec for how you select your resolver, but then still keep in some mention of the fact that, like, you can still penalize and, like, they just kind of non normatively describe how the re resolver selection can fall back, like, happy apples. I'm not big with either.
[00:29:34] Martin Thomson: Yes.
[00:29:34] Ben Schwartz: So so my preference would be something like the, to say DNS res where DNS resolution is performing service b connection establishment, it can also use happy eyeballs as specified here.
[00:29:58] Tommy Pauly: Eric and there's also a poll going on, so chime in.
[00:30:01] Eric Nygren: I was gonna kind of support what Ben said. I think there's enough corner cases here, like, an issue so that if that if we started to expand on this, we could easily turn it into its own draft. There's a bunch of stuff that's covered like, some is covered in RFC to be 10,001, but not but not everything. But I think, as Ben was suggesting, some of these may wanna get pulled out separately.
[00:30:20] Andrew Alston: Yep. There's not a lot of opinions on the poll
[00:30:25] Lorenzo Colitti: I I what is 10,001? Sorry? What does it say? Oh, 3901 BIS. Right. So I think one thing that 3,901 BIS doesn't say is like, you sort a DOH server before a plain text server? And the question that I have here is, should this draft say something about that? For for which like
[00:30:48] Tommy Pauly: like, what is DNS
[00:30:50] Lorenzo Colitti: h e v three, should we say something anything at all about saying, well, we should use DOH over non DOH?
[00:30:55] Tommy Pauly: No. I don't I don't think that's this doc. I think that that gets way bigger.
[00:30:59] Lorenzo Colitti: Then maybe, yeah, we just punt on the entire thing and say that, you know, we use a system dependent or whatever implementation dependent DNS resolution routine. Yep.
[00:31:08] Andrew Alston: That's the way the poll's going.
[00:31:10] Andrew Campling: Andrew Chenka. I think that the question of DNS server selection is not even address family specific because I did have the operational experience of having two IPv4 only DNS servers. And if one of them was down, it was not not optimal. So I think there has to be some description of how that should work. I don't know if it's in this document.
[00:31:37] Tommy Pauly: Stuart?
[00:31:40] Stuart Cheshire: Stuart Joshua from Apple. With spec text like this, I tend to have a preference to have some explanation, non normative text Mhmm. But just a couple of sentences because everybody in this room that's heard all the discussion knows the background, but somebody new picking up this document and reading it might wonder, how does this interface with how DNS works? And just having a paragraph that says what you want to say about trying different paths or different mechanisms concurrently asynchronously. What whatever you think is useful background, then that reader says, oh, I get it. Maybe I have to refer to some other document for the normative definition of this. I I do find those little bits of supporting text helpful in understanding the overall philosophy of why we're designing things the way we are.
[00:32:34] Andrew Alston: I think that's a fair comment as long as it's not too giving too many hints, maybe.
[00:32:39] Speaker 9: Yeah. Yeah.
[00:32:40] Tommy Pauly: It was good good input. Thank you.
[00:32:43] Andrew Alston: Alright.
[00:32:44] Tommy Pauly: Alright. Done. And the very last bit, this is a open issue from Max, so thank you for that, based on Firefox telemetry and implementation discussion. So this is talking about having a exponential connection attempt delay, essentially exponential back off here. So the it it's based on, I think, where you have a notion of, like, a fixed delay that you use. I think, currently, it was using previously, it was using, like, a fixed two hundred fifty millisecond delay, and this is about moving to a shorter delay and then backing off from there. This is something, you know, immediately from my perspective where our our implementation is not using fixed delays and it's using historical estimates for when you use when you have a TCP retransmission, this hasn't come up there. So I think one question is, you know, how much is this specific to using constant delay? Should we be just changing some of those recommendations? Does this also apply to cases where we would have the delay based on the expected RTT and the retransmission timers? I think the question's about should we cap how far we would back off and extend delays in the race. And I think also it'd be good to look at more measurements around this. Max, do you wanna talk about it? Yeah.
[00:34:13] Max Tobler: Max Mozilla. I'll cover this more in my talk in a bit. In general, I'm not I don't have a strong opinion. Whatever value we choose, it's gonna be the wrong one. I think fifty milliseconds is not so relevant, but the exponential back off. In general, I think the draft already includes the idea of you need to implement your own mechanism. So I think two hundred fifty milliseconds at least for Firefox is very conservative. That's why I'm suggesting 50 and an exponential back off.
[00:34:48] Tommy Pauly: Luenza? Okay.
[00:34:49] Lorenzo Colitti: Sorry for doing this, but on the previous point about DNS servers, I know you made it, like, a shocked face when I said, do we need to say anything about sort of encrypted DNS resolvers? I guess one which, you know, I I'm not gonna challenge that. But I think one thing I would like to say is, do we think there will be no dependency in the Happye algorithm on, for example, whether a query was issued, whether an answer was received over an encrypted transport, and should that be preferred? It it's fine if we leave that out of scope. I'm just saying if if if we think the algorithm would benefit from that, we should at least think about that. And I I concur with with Stuart. If we sort of leave this leaving it unspecified and having some text saying, like, here's some things you wanna think about is is is is good too.
[00:35:38] Philip Tiesel: I think
[00:35:38] Tommy Pauly: it's mainly interacting with ECH and how much you trust ECH there, but
[00:35:46] Lorenzo Colitti: I I don't know But, like, ECH itself, basically, kind of if you you in order to do it reasonably, you kinda, like, have to know whether the query was whether the answer's encrypted. Right?
[00:35:57] Tommy Pauly: But I think there's a difference between knowing whether or not you use an encrypted transport and being able to control or influence that. Sure.
[00:36:07] Lorenzo Colitti: But it's it's a bit it's probably not a big step. But but, anyway, if if if if all we need to know is whether it was whether the answer was encrypted, maybe that's fine. Yeah. I'm just thinking, you know, we might decide later that, oh, oops. We deleted this text, but now we need to know. And so yeah.
[00:36:25] Tommy Pauly: Alright. Katie?
[00:36:28] Nidhi Pinamaneni: I think we're running low on time, so I'll go quick. So to the questions, I think this is a good idea we should consider maybe doing the exponential back off. Although, I think we should back cap the back off. In Chrome, currently, we do in the newer code path, we do a static delay. But we are changing towards a more using the historical RTT information. And I think the two fifty milliseconds is probably carried for forward from the second version of the draft. So we might wanna look at the RTT information again and try to update that to be a better
[00:37:04] Tommy Pauly: Updating the default
[00:37:05] Max Tobler: Yeah.
[00:37:06] Speaker 9: There. Sure.
[00:37:07] Tommy Pauly: Yeah. That makes sense. Cool.
[00:37:08] Andrew Campling: Andrew Chang
[00:37:09] Eric Kinnear: Andrew, the queue is closed, actually. But if you wanna hop into people, it'd be good to chat more after the session, but we gotta keep going. Thank you. Alright. Gautam, are you ready? So this next one we're doing before some of the implementation reports because some of those reports reference the concept of optimistic DNS. There's going to be another conversation about optimistic DNS in DNS op on Friday. So the ten minutes that we have here is not going to be enough for us to fully get all the way through all of our thoughts about optimistic DNS. So we're gonna time box that rather strictly here. I very much encourage you all to have lots of conversations between now and Friday. And then on Friday, we will revisit the topic in DNS hop. Sound good? Hold that.
[00:38:06] Gautam Tenneti: Thank you. So as Eric mentioned, this was very much designed as a speedrun to talk about optimistic DNS since it's going to be referenced quite a bit. And this draft was actually a result of conversations that happened in this very working group where we were discussing how does optimistic DNS sort of interact with happy eyeballs and what influence does it have on happy eyeballs. And as we were looking into it, we realized there was value in formalizing optimistic DNS into its own draft. So for folks who are wondering what optimistic DNS is, the short description that I would like to give you here is that it's a client side client side stub resolver mechanism that will return expired cached DNS records, and then in parallel is going to refresh the expired answers with make by making a new query. Before we sort of go ahead, I want to talk a little bit about why do we want to use expired DNS cache records. And as most of you might have guessed, it's primarily for performance reasons. So when you are making a new when you're looking up
[00:39:19] Tommy Pauly: a
[00:39:19] Gautam Tenneti: new domain name, anything, you are going to pay the network cost and that latency is expected. And the good news is that when you every subsequent lookup that you do for the next TTL, in this case sixty seconds, you are going to hit the cache and you're pretty much that lookup is going to be free. And something and that is going to be true for the next sixty seconds or so. And somehow at the sixty one second mark, this answer that was perfectly acceptable till a second ago suddenly becomes unacceptable, and now we are expect and now we are expected to go and refresh refresh that answer. And in most cases, in the common scenario, this answer has not changed. And so now we have unnecessarily taken the performance hit for an answer that we know has not changed for that has not changed. And the way we have designed sort of think about optimistic DNS is in the short form, the application that has opted into optimistic DNS, so it knows that it might be receiving expired answers. Where is the stub resolver? The stub resolver, if it has expired cash expired answers, is going to return those to the application immediately so that the application can start connecting right away. And the important bit here is that it's also going to send a query in parallel to the DNS server so that it can refresh its cache. And on receiving the response from from for this, if the answer has changed, then the stub resolver can essentially let the application know that the answer has changed. And then the application, if the connection attempts using the previous expired answers have not succeeded, can now use this new answer to actually make the connection make new make the new connection attempt. So in the best case, we have eliminated the connect like, the latency. And in the worst case, the cost that we're paying is a failed connection attempt. And
[00:41:29] Lorenzo Colitti: I
[00:41:29] Gautam Tenneti: think there are a couple of things that I'm implicitly assuming as I'm describing the scenario, and there are two enabling technologies here. The first is the asynchronous DNS. We're assuming that the application will continue getting updates from the DNS query even after, like, we've handed it off the expired answers. We expect the application will continue getting answers even after so that we can if the answer has changed, we'll get a new set of answers. And the second is HappyEyeballs, which means that the application will continue trying new addresses, and in this case, the fresh answer that it gets from the network so that till a connection is successfully made, it's going to keep trying. And a succinct way to sort of put all of this together is that asynchronous DNS makes optimistic DNS possible, and happy eyeballs is what makes optimistic DNS safe, which is essentially saying that if your application is not using asynchronous DNS and happy eyeballs, we do not think it is wise to use expired answers. So this is our we know we are using expired records, which seems like a big no no for a lot of folks, but this is doing it in a responsible way. Yeah. Trust me. This draft is essentially based on the experiences from implementing and deployment deploying optimistic DNS in mDNSResponder, which Stuart and Phil have worked on quite a bit. And for as an as an implementation, mDNSResponder, which is an open source project, which ships on all Apple devices, has been shipping this since 2018. So if you use an Apple device, you have been using expired hash records for a
[00:43:38] Speaker 9: very long time. Sorry, I couldn't
[00:43:42] Tommy Pauly: Just
[00:43:46] Gautam Tenneti: knowing it makes it real. And as you will hear in the implementation updates that will come up next, Mozilla and Google are also working on sort of tying in optimistic DNS into their implementations. In terms of next steps, this is something that we have been wondering. The draft is currently targeted towards DNS up, but optimistic DNS, in our opinion, only makes sense in the context of happy eyeballs. Without happy eyeballs, we don't think DNS optimistic DNS should be a thing. Given that, we could make an argument for optimistic DNS to live inside the happy working group. And if folks have strong thoughts about where this draft should live, that should be a conversation that we should have at this working group. Okay? Thank you.
[00:44:41] Eric Kinnear: Alright. We have about two minutes for two very quick comments. And then as we were saying earlier, we encourage you to use the entire week to talk through a bunch of this. We'll also talk to some of the DNS op chairs and and such to sort out some of the dispatch question there. So two brief comments. Go.
[00:44:57] Eric Nygren: Eric Nygren, thank you for writing this draft. I think it helps tease out what I think is kind of the disconnect is I think there's two different things we're talking about. There is the the grace period to go over your TTL by a few seconds to handle some of these race conditions, which is totally reasonable. And I think it's just that we should do it. Then there's the the ignore TTLs for seven days thing, which has massive operational implications, and I think where operations is gonna be major stakeholders in that, and I think has a lot of security and privacy implications even if you do have the eyeballs. So maybe if we kind of pull those two apart, it might be easier to have those as two separate conversations.
[00:45:36] Tommy Pauly: Sure.
[00:45:37] Andrew Alston: We learned in the v six renumbering work that there's a there's a lot of that out there.
[00:45:43] Tommy Pauly: Hi.
[00:45:46] Ben Schwartz: So in the slides, you presented this example with, like, sixty seconds and a request that that comes in right after those sixty seconds resulting in a latency spike. I think for DNS up, I'd I'd like to see that example made a little more realistic because, in in the real world, if you have frequent requests, then you have an open connection that remains open and doesn't, you know, shut off when the TTL expires. So I'd like to see a more realistic presentation with with more realistic numbers about what we're actually talking about in terms of stretching. Overall, I would say my preference would be for this to be opt in. Domains that want this behavior can set a flag in an HTTPS record and even maybe provide some parameters.
[00:46:32] Gautam Tenneti: I don't think I got that, but I can follow-up with you later.
[00:46:36] Ben Schwartz: Right? So, yeah, just an HTTPS service per AMP that lets the domain say, you can be opt do some optimistic stretching on this name for up to two hours past expiration.
[00:46:49] Tommy Pauly: K. Great.
[00:46:50] Andrew Campling: Thank you.
[00:46:51] Eric Kinnear: Thank you very much. Max, I think you're up next.
[00:47:05] Speaker 9: Everyone,
[00:47:12] Max Tobler: I'm Max from Mozilla. And I'll present again the updates that we have, on Firefox, more specifically Happy Eyeballs v3 in Firefox. Since last meeting, we now enabled Happy Eyeball in Firefox Nightly. This means that we have roughly a population of 15,000, very brave Firefox users, running Firefox Nightly, and we have the telemetry of that. And that's my main contribution here where I can share all of that telemetry here. And in the slides, you have the links. All of this is public, so you can look it up yourself afterwards if you want. As a summary, like, we're we're tracking the draft quite closely, but we have a couple of deviations which I'll present. If you wanna try it out yourself, download Firefox Nightly. That's basically our our alpha version. Confirm that happy eyeballs is enabled. It should just be on by default. If you're running an old version, then it might not. And then visit any website, for example, the happyeyeball happy-eyeballs.net website. And there you can test our implementation, but also any other, of course. On some resolvers, we don't have good HTTPS record support. Or if you wanna boost your, like, yeah, probability that you get HTTPS records, then try DOH. K. All of this is implemented in a reusable library. It's on mozilla/hev3 on GitHub. It does it's not aware of what Firefox is, so you can reuse it in your software. It it's deterministic. It doesn't have IO, and it doesn't have time, so you can pass all of that in. And all of this allows us to write really nice tests where we have all the properties of the draft encoded in a unit test. So, for example, if you don't wanna write use our library, you can point your agent at our test suite and then port that to your language. The draft has two timers, the resolution delay, the connection attempt delay. We currently, for the resolution delay, the draft is fifty milliseconds. We currently do twenty five milliseconds. I have another, metric landing soon, which will allow us to do an even better informed decision, and we might drive that down even further. And then on the connection attempt delay, the draft as shown in the previous presentation suggests two hundred fifty milliseconds, and we do fifty milliseconds with a two x multiplier. On the bottom here, you see the timeline where we do at t zero, we do the first one, t 50, do the second one, t 150, we do the third one,
[00:49:55] Lorenzo Colitti: and so on.
[00:49:58] Max Tobler: Okay. Down into the metrics. Yeah. As you can see, our p five to p 99 is varies a lot in terms of connection establishment in Firefox, as in, like, Firefox runs in very fast networks, very slow networks to very far away origins, very close origins. You'll see ten seconds as the cutoff on a lot of these metrics as it's simply me saying, like, after ten seconds, I don't care about the metric anymore. So that's the cutoff. It might be higher. Our connection failure should be thirty seconds, so a little bit beyond that. In terms of failure, failure up until the seventy fifth percentile, detect quite fast. I assume this is either the operating system telling us there's no connectivity or the first hop or the like. But then also the long tail, we do need quite some time to determine that we have no connectivity to the host at all. This is, I would say, the most optimistic slide of happy eyeball overall. Our winning attempt index, as in which of the many attempts we do, succeeds, is the first one, in eighty four percent of the cases. Now this could have, two implications for us. Either we have a really good implementation or two, we're not aggressive enough. And I have a couple of ideas on how we can be more aggressive, later on. In terms of connection attempt count, how many attempts do we actually make? Here again, we only in eighty six percent of the cases, we only do one attempt, as in it almost almost works. All of this work is only for the long tail. Cancel the attempt account. Again, pretty much none in most cases. Time to first attempt, that's between we we decided we want to connect and we do the first connection attempt. So basically, the resolution time. Here's you see in the p fifty three milliseconds, that's mostly just served from cache, either in our cache, the OS cache, or the recursive resolver cache. And then, yeah, this grows quite far. P 99, six hundred milliseconds just for DNS is quite long. Here, I have this later as well. We do do optimistic DNS in all of this. We have been doing optimistic DNS actually since 2013. So, that also explains the p 50 of three milliseconds. Okay. DNS resolution time by record type. Not particularly I just wanna show here, there's not too much of a difference. We oftentimes see the quad a slightly delayed from the a record. You see the HTTPS record significantly faster here in the metrics, but that's simply because in most cases, we don't have an HTTPS record, and so we simply cache the negative and then serve that. Yeah. One major motivator for us to do in all of this is to increase our share of h p three traffic. So how how can we learn about h p three support on the origin two mechanisms, out service or HBSRs? In 35% of the all connections, we upgrade due to a signal in out service. And if you break that down on all h three capable hosts, that's 84%. And in very rare cases, we see an HPSRR record. I'll go a little bit more into that. When we do get that HPSRR, in most cases, it has an h three ALPN. I assume also the main motivator by operators to deploy the HPSRR. We do see hints, and in some cases, we see ECH. In terms of HPSRR features by Resolver, Firefox supports DOH and native through The US system calls. There's not much difference. Back to the idea of h three upgrades. Again, there are two ways, l service and h b s records. We, a browser, want to see more h b three as it, for example, way faster connection establishment. The problem with l service upgrades is that we waste a whole round trip. We first have to do an h t v two or h p one connection, then we get the out service. And then on consecutive connections, we would do the h three connection. With HPSRs, we can do h p three on the very first connection and thus get all benefits off the very first connection. So this is really important for us, and that's why I started a little effort, safe around trip.com. You can check your domain there whether you publish an HTTPS record, whether you publish, Alt-Svc headers, what what the numbers are in terms of Firefox, what we see normally, and you see it will attempt quick to it and see whether your endpoint actually speaks quick. So I would greatly appreciate help circulating that widely and so hopefully see more HPS of ours. Right. Back to Firefox. How do we deviate from the draft? We changed the attempt delay fifty milliseconds to x back half. Overall, we saw good improvements from that. The resolution delay for us is twenty five milliseconds. We're considering tuning that downwards. The draft right now specifies interleaving IP families. That's very important. Right? You wouldn't wanna walk through all of the v six addresses and then try v four only to find out that you're in a v four only network. But we also interleave protocols. So we would try quick v six quick v four, then TCP v six, and then TCP v four. We already do optimistic DNS, and in the future potential deviations right now, we have the, attempt sorry, the resolution delay, the twenty five milliseconds. We wait up to twenty five milliseconds after we got the first positive response, for both our preferred address family and the HPS record. And I'm considering the idea of not waiting for the preferred address family. Most of Firefox's connections are very short lived. Now maybe v six is faster, as in the connection later on will give us the bytes faster, but will it make up for those twenty five milliseconds that are waited for the record up to twenty five milliseconds? So that's the discussion to be had. We had this discussion, Lorenzo, that this might introduce a race where then Firefox switches between v four and v six all the time. In general, let me say, like, if we have both, we would always prefer v six unless the user configures it in a different way. In terms of potential future additions, happy eyeballs allows us a lot more optimizations as in we can be optimistic in a lot more places as we now try to attempt a lot more other things. What would be interesting is to, for example, make our happy eyeball state machine proxy aware. So when you proxy, you have a connection to the proxy and a connection to the origin. So the cardinality explosion that you already have to the origin just blows up times two because you have all these connection options to the proxy, and you have all these connection options to the origin. So we might introduce that, some of that into our state machine. And then the other one, currently, happy eyeballs is not aware of the last application protocol as in WebSocket or web transport, but we might introduce that into the state machine as well and then raise different connections whether we can, for example, do WebSockets over them. Yeah. A couple of edge cases that we hit. DNS negative answers is quite difficult, especially as we don't have details for those on all platforms. DNS coalescing. There is some multi CDN trickery around CNAMEs and HPS RR records. And then a big one for us as a browser, the web standards, we emit various timings, and we really wonder where does DNS lookup end. Where is that? As in, like, is that so this is really difficult. I think Kasha implemented a really good solution in Firefox, but I think we should probably standardize across the browsers on that. Okay. And then I have a little bit of time. A big discussion here from operators is how do we debug API walls, and doesn't this make it super difficult to find any bugs in in our networks? And what we can offer from the Firefox side, and I'm sure a lot of other browsers also expose a lot of debugging tools, is various ways how you can introspect why Firefox made certain decisions on the happy eyeball path. So first, on the very left here, you see about networking. There you find what kind of connections we do. You see our DNS cache, our old service cache, so you can reason about what Firefox had available. And then on the right, I can I'll also show a screenshot in a bit. Firefox also has the ability to capture traces of the happy apple execution, and then you really learn the reasoning of the state machine and why it chose certain path. In general, I already talked to Maria. We could also extend this to emit queue logs for happy eyeballs then in those traces, and that can then be a standardized way for operators to debug. Here, just a screenshot. You see a Happy Eyeball execution. You see that Happy Eyeball got an HPS record in quad ANA, and you see that the HPS record took slightly larger longer than the quad ANA. The state machine waited and then decided to, emit an h e p three connection, over v four. I was, in this case, on a v four only network, and that succeeded. And then we didn't trigger anything, beyond that. So just as an example, in case you wanna learn more, find me anywhere, and I can help you debug happy eyeballs in your network with Firefox. Cool. And then last thing I said earlier, we almost always win on the first attempt. So either our implementation is good or we're not aggressive enough. We can now be optimistic about various things. So we already do optimistic DNS. We have been doing that for very long. We could, for example, be optimistic about our service and keep those beyond the TTL, again, revalidating. And we can do optimistic quick. None of these are happening in Firefox today. All of these would have experiments and so on, but just ideas here. Cool. That's it for mine.
[01:00:50] Andrew Alston: Okay. We'll take the three questions in the queue. We're pressed for time, as Eric said at the start. So take anything substantive.
[01:00:59] Lorenzo Colitti: So Lorenz Scalidi, one of my questions was, in fact, why optimistic quicks? You already answered
[01:01:04] Tommy Pauly: that one.
[01:01:06] Lorenzo Colitti: So I'm curious, you know, given you have so much talent tree, it would be great to know, if you raised the first address with the first address, how would your metrics change? In other words, how much of this is just the statistics of, like, hammering the network harder versus the first address not actually working? I would love to see the answer to that because we we're building something really complicated here. So your your second attempt succeeds, but that, whatever, 10 8% of the time. Right? Your first attempt succeeds 91%. I can't remember exact numbers.
[01:01:43] Max Tobler: Yeah.
[01:01:43] Lorenzo Colitti: But if you replace the first the second attempt with the same IP address as the first attempt, how many times would that actually work? I suspect it would work almost 8% of the time. And so I guess what I'm saying here is, like, how much are we doing diminishing returns? Maybe Tommy has an answer to that. The other thing I had to say but but, like, I think we should try to do that because otherwise because it it will give us an an upper bound on utility of this whole working group. Sorry. Alright. Okay. Now you can always shoot me. Sorry. But, really, if we're all we're doing is, like, sending more packets, let's just send more packets. Right? So, anyway so so I I really am fascinated. I would really be fascinated to to get the answer. The other thing I wanted to say more related to what we're trying to do here is, you interleave protocols because, you know, that's kind of easy, right, v four v six. Now the draft says, let's do sixty seven twenty four, and I think you probably looked at that, and you're like, oh my god. That's hard. Right? And so I wonder whether we should say something else in the draft. I mean, it's it's the only thing that's correct, I feel, but it's very hard to implement in user space. And it's on Android, it's very difficult to do that at all without latency penalties as well. It's just very hard, so I I don't know what to do about that. But
[01:03:16] Tommy Pauly: okay. Tommy, Paulie. I don't have solutions for you, Lorenzo. Okay. So one question here. You mentioned briefly earlier on the HTTPS record usage being low. I guess, how low and why?
[01:03:33] Max Tobler: Usage is high. Didn't find them. As in whenever we have an HTTPS record, we will use it.
[01:03:40] Andrew Alston: Yeah. Yeah. But,
[01:03:40] Max Tobler: like In most cases, website operators don't publish an HTTPS record.
[01:03:45] Tommy Pauly: How often are you seeing the response come back?
[01:03:50] Max Tobler: I I think almost always. Yeah.
[01:03:52] Tommy Pauly: No. No. With content. With content within A non empty response.
[01:03:57] Max Tobler: So for a connection attempt, only in 3% of the cases. Well, if if you add those two, it's in 7% of the cases do we actually see an HTTPS record. And
[01:04:07] Tommy Pauly: is is that like, do you know that you're actually getting the query out all of those cases?
[01:04:12] Max Tobler: I assume so. Obviously, we could have bugs. Sure.
[01:04:15] Tommy Pauly: Or or blockages. And is this the actual the raw number of connections, or is this separate host names?
[01:04:23] Max Tobler: This should be one one connection attempt, so per top level site domain.
[01:04:30] Tommy Pauly: K. For top level site.
[01:04:31] Max Tobler: Sorry. Per domain that we're
[01:04:33] Tommy Pauly: Per domain. Connect. Okay. Oh, but but per domain, not not weighted by the number of connections to the domain.
[01:04:39] Max Tobler: Not weighted by the number of connections.
[01:04:41] Tommy Pauly: Per
[01:04:41] Max Tobler: okay.
[01:04:42] Andrew Alston: So let let let
[01:04:43] Tommy Pauly: let's say, you know, google.com publishes it. Yeah. If if people go to google.com a lot, is that going to increase the number, or is that not going to increase
[01:04:50] Max Tobler: the It's gonna increase the number.
[01:04:52] Andrew Alston: It will.
[01:04:52] Max Tobler: Okay. Per connection establishment
[01:04:55] Tommy Pauly: Okay.
[01:04:56] Max Tobler: As in per happy eyeball processes.
[01:04:58] Tommy Pauly: Because I was looking like, our stats for browser workloads, I'm seeing the HTTPS response for seventeen percent.
[01:05:05] Max Tobler: Positive or negative?
[01:05:07] Tommy Pauly: A positive response in seventeen percent.
[01:05:09] Philip Tiesel: Okay.
[01:05:10] Tommy Pauly: And then in thirty percent of those cases, I actually see that it causes us to upgrade to h three when we wouldn't have otherwise. So we didn't already have all service cached.
[01:05:20] Max Tobler: Okay.
[01:05:21] Tommy Pauly: So it's pretty different numbers there. I would
[01:05:24] Max Tobler: I would still hope for more than 17% overall, but
[01:05:28] Tommy Pauly: yeah. But that's a that's a lot different number to read. Yeah.
[01:05:31] Max Tobler: We need to compare those numbers. Like, I I see very little HTTPS records, and I also when I compare this just, like, trying it out through top flares recursive resolver, like, duration point, I also rarely see websites publishing.
[01:05:46] Tommy Pauly: Okay. Alright. And then one other comment for your proxy explosion. Mhmm. I I think the the way I would suggest solving that is just, you know, connect by name through the proxy. Don't do happy eyeballs inside the proxy.
[01:06:01] Andrew Alston: One more question. It might be an online very, very oh, no. You're here. Very quick. Yeah.
[01:06:06] Muhammad Anas: So I think it would be useful to quantify the increase in network load. So as Lorenzo was talking about crashing of the network, so it should not just be about doubling or quadrupling of packets. It would be also useful to quantify the protocol flapping, how much flapping do you see in between the protocols, that would also be useful and I think given that you have data, it would be useful to the results by network type, show how the results look for a fixed line network versus a cellular network, two gs, three gs, four gs, then it would be more useful to identify what should be the timer value. I think we should not stick on one single timer value, otherwise we'll be again in five years talking about Happy Eyesballs version four. And I'm speaking from experience because my PhD was on Happy Eyesballs, ten years later we are still talking about Happy Eyesballs.
[01:06:52] Andrew Alston: Okay. That's Sounds good. Thank you very much, Max.
[01:06:55] Max Tobler: Thank you.
[01:06:56] Eric Kinnear: Thank you, Max. Kenichi, I think you're up next. And you wanted the revised.
[01:07:08] Speaker 9: Okay, so I'm Kenichi Shibashi. I work on Chromium Network Stack. Today I want to give you a status update on happy hours in Chromium. So let me start with a quick recap. Chromium supported only Happy Happyeball version one and only for TCP. TCP and Quick Run on the separate code passes and each to its own DNS resolution and wait for all DNS responses. So we want to improve the session and we said we were reworking the connection management layer to fix the situation. So they built a single cross protocol coordination algorithm, shared DNS resolution between TCP and QUIC, start attempt without waiting for all DNS responses. And since then, we have been implementing this work in stages. So here's our view. Everything is on top of a new async DNS resolver, which pushes a partial result as each answer arrives, considering the resolution delay. On top of that, we are moving forward with the staged approach. So we are improving the TCP and the QIC code path separately, and then we work towards developing unified cross protocol coordination. And in parallel, we are implementing optimistic DNS. So let's start with TCP. Now, TCP connection attempts to consume incremental resolutions, so that means we connect as soon as a usable address arrives without waiting for all DNS responses. So the resolver applies the resolution delay from RFC 8,305. So when quad delay is still outstanding, it holds IPv4 only result for fifteen milliseconds. As before, we raise IPv6 and IPv4, so the rest just starts sooner. And we are about to shift this behavior and we saw a measurable performance improvement for our services. So next click. Currently, a click attempt to wait for all DNS answers just like the old TCP behavior and tries only a single IP address. So if that address is unreachable, Chromium falls back to TCP even when QUIC would have walked over the other address family. So this isn't a good situation, so we want to fix that. We are working on fix that. So QUIC will get the same VHDB that the current VHDB already has, so that means we start the handshake as soon as that usable endpoint arrives. And if the first attempt fails or is slow, attempt the other address family. The first attempt to succeed wins. In parallel is improving the TCP and the quick code passes, but we are also implementing the optimistic DNS. So we already had the presentation for the optimistic DNS, so I won't go into details, but idea is to start connecting this expired DNS cache while simultaneously creating for fresh DNS responses. So how are we implementing this? So on the resolver side, we've done the groundwork. We added a new cache usage mode, the long name on the slide. In this mode, the store addresses are served as an intermediate result while flashing iteration proceeds. And the final result is always fresh. So regarding the connection attempt to layout side, so TCP is largely implemented and we are planning to do a field experiment. For QUIC, we planned this as the step after moving to incremental resolution. What remains is a unified connection management logic across protocols and address families. So we actually started with cross protocol coordination first, but we learned a lot. So the racing part wasn't the hard part, so the difficult part was that the existing path carries years of optimization and keeps evolving, so the delight has to keep chasing it. And also, in some edge cases, the new code bus makes connection attempts stall or come much slower, so all of these are solvable, but users should not have to wait for the whole delight. So that's why we decided to go through the staged implementation and tack tackled the cross protocol coordination later. How do these works map to the briefly draft? So most of the draft's individual behaviors have been implemented or are in progress. So incremental resolution, connecting to the partial results, resolution delay, other summary relation for TCP and QUIC. So the remaining is cross protocol coordination just I described in the previous slide. Yeah, and to summary, so yeah, we are shifting hardware with behavior and keep improvement and optimistic DNIS are in progress, and we plan across protocol coordination data. Yeah, that's all I have.
[01:14:06] Andrew Alston: Great. Thank you very much. We are only three minutes behind, amazingly, so time for a couple of questions to make sure we do get further behind, if anyone's got any. We'll just yeah. There's two questions. So we'll take those, and then we'll move on if the next person wants to come up.
[01:14:27] Johannes Zirngibl: Hey. Johannes, MPI. One question. Do you plan to raise QUIC against TCP or QUIC against TLS on top of TCP? So is the signal the TLS handshake that is successful, or is it the TCP handshake that successful?
[01:14:41] Speaker 9: So currently, we have totally separate holdup path between the TCP and the QUIC. So we plan to unify it, but currently, so we basically raise both paths at the same time. So there is no interaction between the quick path and TCP path. Does that answer your question?
[01:15:13] Johannes Zirngibl: No. I think that's where the signal ends. Like, is it once TCP is successful or once then TLS on top of TCP is successful?
[01:15:21] Speaker 9: So, Niti, you want to, to cover?
[01:15:23] Nidhi Pinamaneni: I think so to answer your question, we wait for the TLS now to, mark it as successful.
[01:15:34] Andrew Alston: Okay. Thanks. And, Ben, if you wanna come in.
[01:15:41] Ben Schwartz: Hi. So for optimistic DNS, how stale is too stale? When at what point do you cut off stale records?
[01:15:51] Andrew Alston: I've heard this question before today.
[01:15:54] Speaker 9: So would you say that again?
[01:15:57] Andrew Alston: I'm gonna hear it again.
[01:15:59] Ben Schwartz: So for for your implementation of optimistic DNS, how long are you willing to hold on to a stale record?
[01:16:09] Speaker 9: I couldn't do that. Sorry. I I'm not very good at hearing. So could you just say that would you repeat the last part?
[01:16:18] Ben Schwartz: It's a the trouble with remote questions. If a record is stale in cache, is there a limit where you'll just delete the record or decide that it's too old?
[01:16:36] Speaker 9: We have several similar to remove the cache. First, we don't persist DNS cache, so every time Chrome relaunched, the cache is cleared. And the other is like, if we go to the network event changes or something, we also make a mark. So yeah. So that's that's
[01:17:03] Ben Schwartz: Okay. That's interesting. Because then on, say, a desktop version of of Chrome, it could be up to a few weeks old.
[01:17:15] Speaker 9: Can be. Yeah. Okay.
[01:17:18] Lorenzo Colitti: The
[01:17:22] Ben Schwartz: let's see. I wanted to voice my continued desire for Chrome to implement the service b target name capability. I I hope that this work helps to helps to clear the way for sir for service b target names.
[01:17:41] Speaker 9: Yeah. I I I know you are very interested in that that support. So yeah. Yeah. I hope at some point, we can work on that.
[01:17:52] Ben Schwartz: And I wanted to ask what will happen if a quick quick is attempted, and after fifty or a hundred milliseconds, it hasn't completed yet, and you start TCP. If TCP and TLS wins, will you cancel the quick connection?
[01:18:16] Speaker 9: No. We don't cancel quick attempts for right now. So we we let the quick attempts go so that that the next next request can use click, hopefully, so we start succeeding.
[01:18:34] Ben Schwartz: So I I think that's the right behavior, And I think we should make sure that we've talked about this before. I call this connection escalator. We should make sure that the happy eyeballs b three text supports that behavior.
[01:18:55] Andrew Alston: Okay. Thank you. Let's let's move on and get Tommy up. We've got Tommy, then we've got the web tester report. There's been some hackathon activity, and then we're on to the reporting reporting.
[01:19:07] Tommy Pauly: Alright. Speedrun. We've talked about a lot of this before. So HE v three implementation on Apple devices. This is evolution of what we had for happy- eyeballs v two. This is all based on historical RTT data, not fixed timers normally. Recent numbers showing that overall, this is for everything, not just particular loads. We see 97% of things using the first one. So, usually, we don't need this. That's good. The s v c b support was added back in 2020, and that's when we had the ALPN processing. So I just wanna give a brief timeline of some of the updates here because there are couple changes in the betas that you can test out. So it was back in iOS 25 when we started always sending the a queries for NAT six four. So this v six stuff that we're doing, it's it's been a while coming. We fixed shuffling of SVCB records that have the same priority a little bit ago. And then on the current things that are in beta that if you want to test them out on the developer or public betas, that includes only reordering happy eyeballs within s v c b priority groups before it would cross. So we would reorder v four and v six, potentially across different SVCB priorities, and now that will not happen. They will respect the priority. We're also collecting a bit more data around the resolution timings to help inform if we want to update the timers. So as one example of this, and we can get more data pulled out, but Max was talking about the resolution delay timer. So what I I just pulled this yesterday. So seeing the difference at least between when we see a and quad a come back and looking at, like, the absolute value difference between those, almost always there at the same time. P 90 is only seventeen millisecond difference. P 95, 34. P 99 is out at a 100. Currently, we have the timer at 50, so it catches most things. I think kind of it'd be good to compare notes on what we see on different implementations. Do we agree on what the curve looks like here for when we see these come back? And where how do we want to use this to influence where we set that timer? K. So, yeah, we'll continue to update as we make changes to the spec, and we get feedback here. We wanna keep collecting metrics. I think one of the things based on what Max is talking about that we'd like to start collecting is about how many connection attempts we started but didn't end up using. So, like, how often does the first connection attempt win the race, but we started a second one and had to cancel it? We don't currently capture that. We collect just which one won.
[01:22:01] Gautam Tenneti: That's all.
[01:22:02] Andrew Alston: Great. Thanks, Tommy. So time for a couple of questions. The queue is unlocked if anyone wants to quickly ask something.
[01:22:14] Andrew Campling: I think in both reports, I saw a lot of focus on the happy path, so which is very nice. A little bit more on when the failures happen, so when the connection doesn't succeed on the first attempts and kind of echoing what Lorenzo said, is that would a retransmit solve it, or did hackables res rescued? So was that v six failing and v four fixing the connection and things like that?
[01:22:41] Tommy Pauly: And, like, our our timers are based on around the time that the retransmission happens. And the other retransmission does happen. Right? So, like, the first thing does keep retransmitting. But that doesn't tell you if you just kept flooding the same address more, would it eventually work? Hard to say. But, again, like, it's pretty it's honestly pretty rare that we have to fail over globally. I think, you know, there are certain network conditions or certain sites that really need this, and that's what we're trying to fix.
[01:23:10] Andrew Campling: Yep. Because what I was saying is that I think the happy case, happy path probably overflows the statistics that are interested in the unhappy path. I see
[01:23:20] Tommy Pauly: what you mean. Okay.
[01:23:24] Eric Kinnear: Hi, guys.
[01:23:25] Muhammad Anas: Hi. Maybe it's easier for Apple to answer than Firefox for this question. So how much does this drain the battery when you send multiple packets into the network? Might be useful to evaluate that.
[01:23:39] Tommy Pauly: Got it. Yeah. I do. I could not answer that off the top of my head. And all oftentimes, you know, energy usage is about when you're already spinning up the radio and when you're aligning this with the time that you'd already be sending packets, it's not gonna have the worst effects. That's a good question. Okay.
[01:24:02] Andrew Alston: Thank you. So we've had the three implementation reports. I think it's very interesting to see, and I think Max highlighted it more explicitly what the deviations from the draft are in those implementation reports and how much of that is just perhaps different tweaking of defaults and how much is something more substantive. So I think we need to to look at that. But the other perspective, of course, is from observing with something like a web tester, for example. So we're going to hear about that for a while now. Over to you.
[01:24:30] Johannes Zirngibl: Yeah. Thanks. Johannes from MPI. This is joint work with TUM together still. And to be honest, at the moment, it's mostly work by TUM and Tim, who is implementing this. I'm just the one talking and annoying people with it.
[01:24:44] Lorenzo Colitti: So we
[01:24:44] Johannes Zirngibl: have this happy- eyeballs web tester. I talked about it already in Montreal, so two meetings ago. We did this as a research project, implemented a web tester where you can test your client in whatever network scenario you're currently in. Basically, it encodes parameters in the domain name, and then the server treats those requests based on that. We did it for version one and version two back then and are currently extending it to version three and additional tests. So this was the old look, but it drastically changed. We already have on the public website a test for version three. Everything is still encoded in the domain name, so you can change that and test it. We support h u b three, two, and one, basically. And then we serve a QUART A and HTTPS records so clients can make the decision. You can configure different ALPN sets in the HTTPS resource record if you want to. And then we basically have a configurable delay for QUIC versus TLS. So whatever comes there, can be done. We just delay the server hello in the handshake. And then we also delay based on the IP version that is used, so whether it's I p v six or I p v four. We have two options to delay that at the moment. One's, just for the TLS handshake as well, so where we delay, the server hello. You can also configure to do a network delay so that the TCP handshake would also be impacted, but then it's not that fair anymore. So I guess most browsers currently want to test just where TLS is delayed. At the end, it somewhat looks like this. This is a test result on Firefox, not the current nightly version with the new connection attempt delays, but a slightly older one. What you have in the result is then a matrix, of all the tests where, on the x axis, basically, the TLS handshake is delayed for QUIC versus TLS TCP and on the y axis, the protocol version. So it starts with QUIC via I p v six. If I p v six is too slow, it goes to QUIC via I p v four. If QUIC is too slow, it first tries TLS TCP over I p v six. And then once again, if I p v six is too slow, it falls back to I p v four. So this is somewhat the the default behavior that you expect with a static connection attempt delay and the order quick over TLS TCP and then I p v six over I p v four. You can use the matrix and run the test on the website, or you can just, get the domains that are used. So the configuration, you can download and create your own order of tests or just run one test if you want to. We also added additional, debugging or information by now. So we collect the trace of incoming packets on the web server as well and surf that again so that you see, to some degree, what we saw on the web server. This is not perfect depending on whether we actually see a domain and can map it to one specific test case, but you see in which order the traces arrived or the connection attempts arrived. We now, in the hackathon, extended this to also, report in which order the DNS queries arrived at our name server to extend this trace. Good. And then we also added a lot of other tests that are not all of the API well stuff, but are related to that. We have a test that quickly shows you whether your browser in your current configuration even supports h t p three, so whether it uses or requests an HTTPS record and uses that, or whether it only works with an alternative service header or not at all. Also, all of the following results are Firefox. We added a test whether ECH is used, so whether it also gets the HTTPS resource record there, uses it, if the configuration is stale, whether it does a retry if it gets a new, configuration, or if it doesn't work at all, whether there is a plain text fallback or no fallback at all. We added different tests by now for HTTPS alias mode. So whether it follows, an alias in the HTTPS record or whether it follows, a port that might be in the HTTPS record. And I think there's also a test where it follows the target name in an HTTPS record in service mode just to see what your client currently does. We have a test that checks whether hints are used or preferred over additional a or quad a records if they are there. There is currently a bug in Firefox or an unexpected behavior, I call you out here, that we found yesterday with this tool where sometimes a record is used and sometimes not. And then also, we have one case where we delay the a record. So QUART a is fast, but then the TLS handshake or QUIC handshake is, in theory, slow to check whether the connection attempt is tested. And then if a quad a record comes in late, whether that is actually used asynchronously and feed it back into the state machine and test it. Yeah. That's basically it. Happy- eyeballs. There is apparently a happy eyeballs without the dash now as well. If somebody knows who operates that, please let us know. We would be interested. We don't know yet. It tests slightly different stuff. Most of the tests are not on the hepb-iball.net site yet, but on the staging one, you get the staging one here. We don't promise anything there. It might break, but all of the new and smaller tests that we developed also during the hackathon are there. In general, we are happy about all feedback or requests, whether you see other tests as interesting or additional features, so we are happy to discuss this, and extend it. Thanks.
[01:31:10] Andrew Alston: Great. Thank you. Excellent work. Time for one or two quick questions, if anyone has any. If not, we'll move on to the first reporting draft, QLOC.
[01:31:35] Mirja Kühlewind: Hi. My name is Mirko Levent. I can start talking while the slides come up. So part of the charter for this working group is also that we wanna work on reporting. The discussion when the group was chartered is that happy eyeballs makes the user happy, but maybe not the network because errors get concealed. So we want some logging to find those problems and actually fix them. The first step zero to that is actually kind of getting the errors locked. Right? This is very useful for debugging. Think it's useful also for debugging purposes to have a common format so we all can find the same problems at the same time. But then the next step is also kind of to use this format potentially to report out some things and allow other people to analyze what what are the problems when the second attempt, not the first attempt, is successful. Again, step zero is the format. I put a draft out there based on QLOG. It's really an early version. Everything is open for discussion. The slides are not having a lot of details because at that point, I'm not even sure I got everything correctly from the draft. I need to do some more work there. Even my version on GitHub has changed already because I found some redundant, unnecessary stuff. But I think it would be useful if people who actually haven't had the implementation also look at this and potentially implement that, figure out how hard it would be to implement this into their stack and if I found the right things or not. So what we have is I said this already. So what we have is what is in the draft, and again, I am not going through the details here just to give you an impression, is three data types. So one that carries all the information about the attempt itself, which is kind of post address, interface, and so on, but also LPN and service name and these kind of related data. The other one is what's called a policy. That's kind of what you configure, what are the default values in your strategy. And the third one is about the DNS resolution results. And then it defines a whole bunch of events. Like, one the first one is, like, when you set the the initial configuration or reset it. Then some events related to when your DNS started, when it finished. It covers the net for six cases. It's about candidate discovery, like how to put together your list about which candidates you try and when you change these lists. And then it's about when you actually start an attempt, when you finish an attempt, when you resume an attempt, when you have pending attempt, timers, the results, of course. And then we also added one event, which is just kind of the summary logging at the very end. And this is the only detailed slide I have. This is what's currently the summary logging, but I think this also more discussion about, like, kind of Tommy and Max said this about, what are the metrics that are actually interesting here? So yeah, I am looking for people who want to work on this with me, who want to implement it. I talked to Max already. They already have event based logging, and I will look at their format and figure out if kind of things are matching up. And I am also interested in getting or analyzing more of those data where the first attempt failed, and understand what the reasons are.
[01:34:53] Andrew Alston: Great. Thank you. So, we've got time for one or two questions. Part of it will be to whom or to where is reporting being made and for what purposes, etcetera. I think we're going to get some of that in Philip's talk after this.
[01:35:07] Mirja Kühlewind: Yeah. Exactly. I mean, this is step zero and it doesn't touch this question, but
[01:35:11] Gautam Tenneti: Yeah.
[01:35:11] Andrew Alston: That's part of it.
[01:35:13] Lars Eggert: Hi. Lars Eggert, Mozilla. You said operator. Do you mean the network operator or the website operator, or we don't know? So so the the question so we can totally log this in the browser or somewhere else, but how does it get to where it needs to be Yep. Is the hard part. Right? Not not what does what is being logged. It's like do you have a proposal for how that happens?
[01:35:37] Mirja Kühlewind: Yeah. I mean, like, I'm thinking about network operators, but, like, I think what we need to do is getting the data and understanding where we are, and then we can figure out what's useful. Because, I mean, part of the discussion was also that this is actually a rare case. Right? That, like, in most cases, you just take the first attempt. Everything is fine.
[01:35:55] Lars Eggert: Yeah. I I totally see the problem space. Right? Right. And but I think the proposal is that the browsers or the endpoints log something. Yeah. And that something gets to where it needs to be somehow, and the somehow part is, I think, the hard part. Yep. Not the what you log and how you log it. That that is is not easy, but at least well understood, and this is good. Right? Yep. But I think any idea of how it leaves device and gets to where it needs to be in a way that's terrible?
[01:36:21] Andrew Alston: Yeah, I think you're getting onto the subject of the next talk. Alright. You've got specific comments about what's there then?
[01:36:28] Mirja Kühlewind: I wanna say one more thing. Right right now, I'm just I'm I actually want to get some data and analyze it, and that's kind of, you know, offline. Right? So I can talk to
[01:36:36] Lars Eggert: somebody who
[01:36:37] Mirja Kühlewind: gives me some data. If we need something that works online or in a different time scale or whatever, that's something I think that we can answer better if we if we know what the data are.
[01:36:45] Lars Eggert: Okay. So so if you're just interested in, like, running a a thing and getting data out in in some locally analyzable format, that that's fine. I I misunderstood probably because I thought that data was supposed to go, like, to a central aggregator or something.
[01:36:57] Mirja Kühlewind: At some point, maybe. I don't know. Like, I'm not there yet. Sorry.
[01:37:08] Andrew Alston: Is that Ben again?
[01:37:09] Ben Schwartz: Reports. Is this meant is this HE metrics object meant to go in Qlog?
[01:37:17] Mirja Kühlewind: Yes.
[01:37:18] Ben Schwartz: Okay.
[01:37:20] Mirja Kühlewind: So, I mean, it's not really an event, but it's like when you actually finish your your happy eyeballs thing, then you just put this kind of pseudo event in there. Yeah.
[01:37:30] Ben Schwartz: Okay. Yeah. I think, like, for the kinds of debugging that I I've had to deal with, I would want a lot more
[01:37:38] Mirja Kühlewind: Yeah.
[01:37:38] Ben Schwartz: Information than this. And when I think about Qlog, the thing that that I would really like is a way to I think that we kinda have all the information in Qlog about the fine details of everything that happened. What's missing from my perspective is, so first of all, maybe there's things that we're missing, like DNS related events. I don't know if we have Qlog events for that.
[01:38:05] Mirja Kühlewind: It so can I I think a lot of the debugging, you can actually like, there's also the events, right, when things are actually happening?
[01:38:11] Lorenzo Colitti: So you
[01:38:11] Mirja Kühlewind: can put your you do your analysis on the events. Right? And that has a lot of more information. So this is really just, like, aggregated metrics. Right.
[01:38:19] Ben Schwartz: Yeah. So the the aggregation, I don't that's not what I need. But the other thing that I feel is often missing is a way to thread all of these, details back together. You have the HE session ID. I think that that's kind of that seems like a really valuable thing to be able to say this, you know, this TLS session over here and this quick session over here, they're actually, from a single connection attempt.
[01:38:45] Mirja Kühlewind: Yeah. So we, for some of these events, we put kind of an identifier in there to, like, cross correlate this with the quick connection with the queue logs of the quick connection. But I think there's also more work to do here. Yep.
[01:39:01] Ben Schwartz: I wanted to mention that I have a pull request up for the h e v three draft that tries to make the connection sequence state machine much more explicit and technically technically detailed in a sense, which I think really connects with this. Because when you're at the point of trying to look at this level of granularity about what is happening, well, we don't the standard doesn't actually specify h e v three at that level of granularity yet. And I think that we should do that work on the text. So please take a look at pull request one twenty five on the h e v three draft.
[01:39:40] Andrew Alston: Okay. Thank you. So, Philip, do you wanna come up while Lucas presumably asks a quick question?
[01:39:45] Lucas Pardue: Yeah. Just to say, I think this is good work. It's obviously draft zero, and there's lots of kind of things we could shed on. For me, it's like the DNS has probably been split into its own stuff as a queue log schema, but none of these details matter. Just from my perspective, as someone who's had to debug, like, and how it's managed its connection pool and where h three has failed and h two worked. I'm looking at those kind of events anyway quite a lot. So having a standard for that, I think, would be really useful. The question of threading of the session IDs and all of this is is super important. I don't have an answer, but we definitely need something like that for Q log to be successful in threading transport, DNS application, all of these related things. So, good work. Thanks.
[01:40:28] Mirja Kühlewind: Thank you. Yeah. And like we talked about this earlier, like I didn't even think about that this is, like, more generically applicable, but that might be a good way to go. Yeah.
[01:40:35] Andrew Alston: Yeah. Great. Thanks very much. And over to Philip for
[01:40:41] Philip Tiesel: Yeah. Welcome. You the clicker?
[01:40:44] Andrew Alston: You've only got one slide, or do
[01:40:45] Max Tobler: you want
[01:40:46] Johannes Zirngibl: the clicker?
[01:40:47] Philip Tiesel: You can click.
[01:40:48] Andrew Alston: Oh, I can click. That's very kind of you.
[01:40:54] Philip Tiesel: So, we're talking here today now change a little bit positions and look to the operator's perspective. And which kind of operators, I'll come to that later. Now this draft, in case you haven't read it, is just about the use cases. So who needs insight into happy eyeballs, what and when to report, and security and privacy considerations basically saying when and why not to report. Between the last revisions, we reworked the use cases and introduced a much more agile kind of description with personas who want or who need information on Happy Eyeballs. We wanted to describe what, when and how example match the personas and more minor changes. So let's look into the personas or into the kinds of person who wants insights into happy eyeballs. And the first case, we just see developers and users debugging connection behavior from their local system. So they are sitting in front of a browser or a mobile device and really want to see what has been going on during my current session. In this case, let's say a little easier. You have full application, have full client control. You have no aggregation requirement, but because you're really interested in the stuff you're actually doing at the moment. And it probably has the least standardization requirements because if you're sitting in front of a Firefox browser, can use the Firefox profiling tools which I've seen yesterday. It really looked cool for that use case. And if you're sitting in front of Chrome, you can use whatever tool Chrome has for you to debug that stuff. The second use case is corporate and managed network operators. So we assume in this case the network operator is actually also operator of the device, has administrative control over the device. It may have some aggregation and integration requirements, especially fitting into the logging infrastructure, fitting into the client management infrastructure. But it's still they have administrative control about the device and may or may not already have means in invading users' privacy. Even backed up by some legal means or contractual means. The third use case, we go now back to the service providers. So the first layer carrier that wants to have some insights on why probably because of their faults, happy eyeballs or V six or quick connections fail. We have the further downstream case of intermediate transit providers who might want to have insights into why this happens. And finally, have the content providers and CDNs. So this is not ordered by importance, but by distance from the client. And what I would like to ask, and you know, get quite early on interactive, what I would like to see is whether these personas make sense for you in the room. Whether you think anyone is missing in this listing and whether you have a strong opinion whether we could merge some of these personas for the later discussion.
[01:44:43] Andrew Alston: I think if you get through to the end of the deck and then we'll have the chat, that be the best way of doing it. From the Chair's point of view, we want to kind of understand the time. I think a lot of your follow-up on the other three slides, I think, you've got are kind of related. I think we can have that discussion when we You're get to the
[01:45:02] Lars Eggert: saying wait for the questions.
[01:45:03] Andrew Alston: Yes. Wait for the discussions then. Think it would be saner for
[01:45:06] Philip Tiesel: The second one is what and when to report.
[01:45:09] Andrew Alston: Okay, clarifying questions. As Eric says, yes. Other questions, no.
[01:45:14] Philip Tiesel: Second one is what and when to report. So, on I would say it depends on the persona, depends on the privacy implications, It depends on the security application and it depends on the aggregation requirements. And I think for further discussion, further evolving of the draft, the interesting question is do these dimensions make sense or how many dimensions for the further discussions are missing. And last but not least, to give us some idea where this could end up, is a list of examples what this kind of framework for discussing the reporting use cases could end up with. So we have the developer use case and this could end up with happy eyeballs output in some kind of development or profiling tools. It could be some of the performance logs which already exists in various formats. It could end up in the platform logs, so something like Windows events, systemd, the macOS logging. We have the managed way where we can have platform logs or something like Anycast Syslog, just as an example. We have the service providers where we could also think about something like anycast disk lock or an ICMP or other UDP based thing looking a little bit like HEPSAD. But which Brian promised, we have the intermediate thing where I could only imagine something like HEPSAD. And we have the content providers where we can end up with a complete now, the ECMAScript objects, network error logging, and some other frameworks that are already there to report back behavior to the content providers and CDNs. And with that, I'm happy to take first clarifying questions and afterwards start the discussion.
[01:47:15] Andrew Alston: Great. Thank you. So yeah, we've got five or six notes. We'd like to give Xipeng at least a couple of minutes to flag his draft if we can. But let's see how the discussion goes. It's obviously attracted a lot of people to the queue, including Brian, which I think is good. We might hear something some comment from him about happy sad as well. So Over to you, Lars. Let's see how this goes.
[01:47:34] Lars Eggert: Lars, got Mozilla. I don't have a clarifying question, so if anybody else wants to go first, I can't get out of queue because my left
[01:47:41] Andrew Alston: Just go for it. I don't think anyone does.
[01:47:45] Lars Eggert: I got up when you had the the personas up, and you asked whether some of them could be merchant or so. So between one and two, I don't see, like, a material difference. Right? And they I I can see, like this is what Mia talked about. Like, a local developer, like, wanting to understand what is the browser doing. I I I fully wanna support in some way, and I think if the the browser and other endpoint vendors wanted to, like, find a common format to make that a little bit easier, I would be sympathetic to that. A managed device, for all intents and purposes, the the entity managing devices, they're not the user anymore, but I see this as almost equivalent. Right? We can't stop the enterprise from doing what they wanna do, so that's fine. For almost everything else there, I have really bad bellyache. Network error logging, maybe, right, because the this is actually, the server, and we have some we went through that battle before, and and maybe there's something that can be exposed. But even there, I'm skeptical. And and service providers and transit providers, I have no idea why I would, as a browser, wanna expose anything to them ever. And I'm happy to begin this otherwise, but, like, I would really focus firstly on the on the end user or their standard, which would be the enterprise thing, and then maybe to the CDN in some framework like network error error logging exists. But otherwise,
[01:48:59] Philip Tiesel: no. To be honest, I have not strong opinions on whether we need all these use cases. These are the use cases we had discussed or that has somebody has brought up. And I think it's important here to come up with a decision or idea.
[01:49:13] Lars Eggert: So so thank you for being exhaustive, and I'm happy to hear that maybe some of those cases we will disregard.
[01:49:19] Andrew Alston: As the hinges there, do not shoot the messenger. I think they've done a really good job of kind of scoping out what we might do. It's not Philip isn't saying we should do that. He's just asking the questions. I think Philip and Geordie have done a very good job on being there to have the tomatoes thrown at them. Andrew next.
[01:49:36] Andrew Campling: Do you think there should be a way to indicate that you have a policy of how you think it should work? Let's say you you are exposing the content and you are expecting it to work in a certain way and the happy eyeballs would somehow signal that it works improperly. That would as well indicate that you're willing to do something about it.
[01:50:01] Philip Tiesel: Good question. Haven't thought about that dimension yet. Jordy, do you have something?
[01:50:09] Andrew Alston: Oh, okay. You're in the queue.
[01:50:12] Speaker 21: Mike Blanche, independent consultant. Thank you for, yeah, as you say, putting the exhaustive list down. I think between the two ends of that list have some sort of relationship. Right? The user and the content provider and the CDN that's fronting. The managed network as well, as Lars says, probably if it's if it really is a managed device. Service provider can mean a lot of things. Right? Is it if I'm roaming, is it the network I'm roaming on? Is it my home network? Is it if I'm using a private relay, is it that? Are they are are they a service provider as well? There could be ways of providing information to those intermediate providers, the service providers and the transit networks, from the endpoints or from perhaps from the content provider. A lot of the content providers have web portals that transit providers and ISPs have access to that can expose some of this information. But giving it to them directly, similarly, I have some concerns. But thank you for putting it together.
[01:51:14] Martin Thomson: I would like to note that most of these personas already can get most of this info about happy eyeballs. So, like, the end users could get it as key logs or performance profiles. Operators could get it from p caps or whatever other network traces they have. And, like, websites, like the web tester we saw earlier, can do their own thing and get all this information again. So my question is, we already do a bunch of, like, extra work with happy eyeballs creating new connections. So, like, why should applications do a bunch of more extra work to also report of some of this information that the all these personas already get? So this question I can So if you ever had discussions with operators on Happy Eyeballs,
[01:52:00] Philip Tiesel: they say, Oh yes, it's awesome that it solved the problem, but it actually hides so many problems that debugging has become quite hard for us. And we have no idea whether we have an IPv6 black hole because Happy Eyeballs just glosses over that and falls back transparently to IPv4. This is the discussion you have always when talking to operators. And here, really, case is that we want IPv6 deployment, that we want to make sure that it actually works. And any signal that helps with that is useful. As an operator, you have no chance of running a PCAP just in case to find out whether someone has an IPv6 backhaul.
[01:52:49] Martin Thomson: Sure. But even if we did give them all this information, it's no guarantee that it would be actionable so that the service provider could do anything to fix things. So I'm I'm pretty sure
[01:53:00] Philip Tiesel: that the first and the last use case are the most actionable and easiest ones.
[01:53:08] Mirja Kühlewind: Yeah,
[01:53:09] Brian Trammell: so hi, Brian Trammell. I feel like I was summoned to the microphone when Philip said that I had promised happy sad. Happy sad is not a promise. It's somewhere between a threat and a joke. And yeah. So I I it it actually, no. It's more of a thought experiment. Right? Like, so what tools do we have for being able to put additional information in those PCAPs that operators are using that they would be able to pull these things together? I don't actually expect it to become a real thing. I had Claude write a security consideration section for the document. It's now six times longer. But I think it is an interesting thing to think about. So, like, I am gonna revive that document and we can use it sort of as, like, sort of a a test study here. I if if we end up implementing it, I think that's probably an error message in and of itself. But we should think about what, like, what are the ways that we could expose this information as as as easily as possible.
[01:54:04] Andrew Alston: Great. Thank you.
[01:54:05] Brian Trammell: Xipeng, if you uses it is another question.
[01:54:07] Andrew Alston: Xipeng, if you're in the room, if you get up here very fast, you're gonna have about three minutes while Jordi asks his co author a question, which is a bit weird.
[01:54:14] Jordi Palet: Jordi Pollet. Just for context, I am the troublemaker with this. Think it goes nine years ago, I started asking for error reporting. And the explanation why, I have been asking for the error reporting is because my customers are mainly ISPs and also enterprise networks, and they sometimes get a wrong or bad deployment or whatever bad situation which I p v six and happy able goes, hiding that. Okay? So we really need an an I I was not realizing that also this is useful for developers because I am in a different in a different type of business. But we really need that when an enterprise network or an ISP is getting some troubles with I p v six, they get some kind of reporting. So that was the reason. Now what I am missing is in the working group, a discussion about which persona is the most important one in case we cannot achieve several of them and how we do the reporting to this to this different personas. Okay? So that's that's the thing. I I I believe that if we don't have in the mailing list, because here we don't have time, a serious discussion about how we proceed, we will end up with additional nine years discussing about the same. So please go to the list and and let's have a discussion on this.
[01:55:48] Speaker 9: Yep. Okay.
[01:55:49] Philip Tiesel: Probably, it's not the question what's the most important persona, but which personas we can serve easily and which ones we might not be able to serve due to security and privacy considerations.
[01:56:01] Tommy Pauly: Yes. You
[01:56:04] Andrew Alston: finally mentioned the p word there. Yes. Okay. Right. So we've got like five minutes left. So, Xupeng, if you can highlight your work so at least the working group in the room is aware of it and can go and look at it. And then we'll have a wrap up. So over to you, a quick one.
[01:56:19] Xipeng Xiao: So I recently published a draft in v six op. It's called enhanced build stack. It aims to accelerate the enterprise IPv6 adoption. Because without it, I'm concerned that maybe a decade from now, you know, still many enterprises, especially small and medium enterprises still, you know, on I p v four. So what is this enhanced your stack? And why we need it? In short, I feel that the current your stack doesn't work, well enough. Supposedly, you know, when you deploy your stack, the ideal way should be that, you know, if I p v six works, then it's used. If I p v six doesn't work, then I p v four is used. And therefore, for the person who deploy dual stack, there should be no, you know, disturbance of user experience. And if this is the case, then it will be very easy for enterprise to decide to deploy the old stack. Because, you know, you deploy it it will not affect user experience. And if there are I p v six problem, I will figure out, you know, for example, with these reporting mechanism that we are talking about. Fix the I p v six over a problem over time. So, you know, the aim is trying to make, you know, I p v six very easy to start. And fix the problem over time. But this is not the case. Why? Because today, you know, a dual stack host. When you try to decide whether to use I p v six or I p v four, it basically, you know, use the, IFC, sixty seven twenty four rules. And sometimes the rules may select I p v six even when I p v six is broken. And as a result as a result, because it can be broken, then, you know, before the deployer switch on I p v six, he must do a lot of validation work to make sure that, oh, you know, everything is tracked and, you know, it's going to work. And and they face the judgment moment when he switch I p v six on. So I think that, you know, this
[01:58:46] Andrew Alston: problem One minute.
[01:58:48] Xipeng Xiao: Severe because then it's a too much work and too risky. And this is why user are not deploying it. And this is also why we believe that if, you know, enhance the stack is to to get, you know, the stack to ways b is like If I p v six work, then use it. Otherwise, use I p v four. So how do we do this? Basically, we need three enhancement. The first one is OS implementation profile. Happy eyeball already, you know, move the traditional deal stack. One big step towards enhanced deal stack. We just need, to have a OS implementation profile, so that the most number of application can benefit from it. Otherwise, if happy eyeball is implemented by a application, then other application may not benefit from it. And the second, enhancement is the traditional application who continue to use, you know, get address info or connect, etcetera. They also need to be enhanced to take performance into consideration. Currently, IFC, sixty seven twenty four say that you can consider, performance. We want to change it to use to consider performance and also specify, you know, how you take a performance, into consideration. And the last one is the reporting mechanism that we talk about. I think that, Mia talk about, Philip talk about. If I p v six is not selected, why? So that, you know, we can try to identify and fix the problem. So this is the last slide. The key point is that we need a OS implementation profile from the happy working group to benefit the most number of applications. And also, we needed some supporting some, you know, error reporting if I p v six is not used. And with this, I want to, you know, invite people to look the the draft and provide your comment. And because we are from the operation background, we really hope, you know, the better can get involved and help, you know, do this to accelerate enterprise adoption. Thank you.
[02:01:16] Andrew Alston: Thank you very much. We just, Eric and I, just need a couple of minutes just to wrap up. We'll do that now. Eric, do you want to say something first? Okay. So, yeah, thank you everyone for the contributions. It's been almost as incident packed as the third place playoff match. The England six, France four. I feel like I'm being blown away by everything. I think it's been really great to finally get some, it looks like we're heading to consensus on the main draft. I think what we need to do is have more discussions through the week. Eric and I are just the referees of this match. If you like, it's up to you guys, implementers, people writing the draft to to get together and talk to each other and head towards that consensus. And hopefully, over the next two or three weeks, that consensus can be reflected into the draft, the rest of the v six part for example, and the implementers. I think what would be interesting from our point of view is to understand, as I said, Max made it quite clear in one of his slides what the deviations from the spec were. It'd be interesting to see from the other implementers something similar to that and look at what the common differences are. Are they just the default values that maybe need tweaking in the draft other other things to get some consensus on that as well? And the reporting topic, clearly we need to take that forward as well. I think the last thing I'd say is procedurally in the charter, we're supposed to finish this work by the end of July, which isn't going to happen. The ADs though have said they're very happy for us to just kick that down the road a bit. I think the important thing is we've got some great implementations moving forward. We've got the draft in a really good shape. So if people can just put a little bit of effort in over the next two or three weeks to to get that almost over the line and we can then consider a working group last call, which obviously then gets other eyes to come in and look at it as well. Thank you very much. Eric, do you want to add anything?
[02:03:04] Eric Kinnear: Thank you, and thank you, Brian, as he had to stroll away for taking notes.
[02:03:08] Andrew Alston: Great. So with that, we're done. Thank you very much, everyone. Indeed. I'm not quite sure what went wrong with the clicker. I'm pretty sure the light
[02:03:29] Martin Thomson: was on.
[02:03:30] Andrew Alston: The light was on and every