Ben Schwartz: I thought the MTU issues were fragmentation-related, not header-size-related. Please have a fragmentation person review this.
Establishes §4.1 rules for which queries to send based on PVD routes: query A if global IPv4 is available; query AAAA if global IPv6 is available; query A if a NAT64 prefix is detected. NAT64 handling simplified — clients discover the prefix via RA or ipv4only.arpa; if present, synthesized IPv6 addresses are treated as IPv4 for sorting and grouping. Eliminates the "last resort local synthesis delay" timer.
Jen: if you have synth-v6 and real v4, in case you have more specific routes for v4... this would solve the VPN case. we'll discuss it on the pr
Philipp: vpn case will more or less be the same issue as the pvd... what could go wrong? wrong resolver -- that's a different PVD. PVD context and routes are bound to the VPN. getting PVD right should cover all VPN cases.
Tommy: "pull it up into a broader section" as Erik Nygren said. A purist PVD standpoint would keep the answers completely separate. there are split-tunnel cases where the deployment expects to violate this... implementations do resolve on X and connect on Y, which would make this cause breakages.
Lorenzo: we didn't add any mechanism to declare absence of info in a PVD, so you can't easily default-in parts of another PVD. that's the VPN case and the challenge here. wonder whether we should fix that in PVD. this doc should give pragmatic guidance. does the PVD doc think a VPN is a PVD? not clear.
(whether the draft should specify how to sort recursive resolver addresses)
Lorenzo: ...penalizing non-responsive is fine, but keep sorting from the DNS side as to which candidate / protocol to use otherwise. RFC 6724bis already specifies address-family sorting — could just reference it.
Ben Schwartz: just put a long comment on this PR. we should try to stay out of this. dns connection optimization is a different problem space. easier to understand if it's separate. six transports for dns.
Tommy: would like to get a sense of the room as to what direction to go.
(poll: keep and iterate or remove entirely — clear preference in the room to remove detailed DNS resolver selection from the draft)
Andrew Yourtchenko: there has to be some description of how it works when one
Stuart: i tend to have a preference for some explanation as to how this should interface with DNS, for people who pick this doc up cold. ok to be non-normative, just to help in understanding the philosophy.
Lorenzo: do we think happy will want to decide based on whether an answer was encrypted? i concur with stuart.
Tommy: mainly an ech discussion, no?
Lorenzo: to do ech you have to know the answer was encrypted or not.
Max Inden: proposed replacing the constant 250ms connection attempt delay with a 50ms initial delay followed by an exponential (2x) backoff.
Tommy: Apple's implementation doesn't use fixed timers — it relies on historical RTT and retransmission timers.
Nidhi: Chromium is also moving toward using historical RTT.
(group agreed to look at reducing the recommended default timer values in the draft)
(timeboxed, to be discussed in dnsop)
Stub resolvers immediately return expired cached records to the application while firing an asynchronous background refresh query. Async DNS makes optimistic DNS possible; Happy Eyeballs makes it safe (the app can fall back to fresh addresses if the expired ones fail). Shipping on Apple devices via mDNSResponder since 2018; Firefox and Chromium are working on similar integrations.
Erik Nygren: distinguish a short grace period (transient races) from ignoring TTLs for long periods (e.g. 7 days), which has real security/operational implications.
Ben Schwartz: could let domains opt in / tune optimistic TTL extension via a parameter in HTTPS records.
(currently targeted at dnsop, but depends heavily on HE safety guarantees — could potentially progress in HAPPY)
Lorenzo: if you race the first address with the first address, how would your metrics change? how much of this has to do with you're just hammering the network harder? are we measuring the efficacy of HE or its side-effects? this would give us an upper bound on the utility of this whole working group. if sending more packets makes it work... just send more packets! you interleave protocols. i'm guessing you looked at the draft and it said use 6724, and you said... that looks hard. would be good to get guidance.
Tommy: whenever we have an https record, we use it. Max: only 3% of website operators send an https record. Tommy: is the query going out properly, or are there bugs? my numbers, i see 17%, and it causes an h3 upgrade.
Johannes Zirngibl: do you race quic against tcp or tls/tcp; is the signal the tls handshake?
Kenichi: totally separate codepaths currently
Nidhi: Chromium waits for the TLS handshake to complete.
Ben Schwartz: What happens if QUIC is attempted, and tcp/tls wins but quic works, do you fallback?
Kenichi: no.
Ben Schwartz: we should make sure the hev3 text supports this connection escalation.
Ben Schwartz: what are the stale-cache lifetime limits (optimistic DNS)?
Kenichi: cache is cleared on browser relaunch and on network changes, though on desktop it could persist for weeks.
Andrew Yourtchenko: i see a lot of focus on the happy path, can you characterize the failures? would retry solve to?
Tommy: the first thing does keep retransmitting, doesn't tell you whether flooding the network would make it better
Vaibhav: battery life?
Tommy: if you're aligned with the radio is already up, not terrible. probably.
Lars: which operator? I can log this, how can we get it where it needs to be?
Mirja: I'm thinking about network operators. For right now, offline. Online, we need a new architecture, but we need the data model first.
Ben: we'd want a lot more info for debugging use cases, maybe there are qlog events that are missing, e.g. for DNS?
Mirja: events are also there. this is just an additional aggregated summary.
Ben: often missing is the way to thread all the details together. HESession seems very useful. I have a HEv3 PR 125 up to make the state machine much more explicit, which connects with this.
Lucas: this is a -00 but i like it. dns should be its own qlog schema? a standard for these events, threading and session ids super important.
Lars: personas: dev/users, fully want to support. makes sense. managed devices is basically the user, almost equivalent. for almost everything else there i don't like it. NEL: that the server, so maybe, but even there, skeptical. no idea why a browser wants to expose anything to them ever.
Andrew: is there some way to additionally signal expectations / willingness to do something about it?
Mike Blanche: the two ends of the list have a relationship. the middle, no existing relationship. there could be ways to expose that info from the endpoints.
Valentin Goşu: most personas can already get this information... why should apps do yet more work? think about actionability.
Brian Trammell: happy-sad not a promise, something between a joke and a threat. reviving the draft. better to think of it as a thought experiment.
Jordi: nine years ago i started asking for error reporting. my customers are isps and enterprises. their bad situations with IPv6 were hidden by HE. i'm missing a discussion about which personas we care about.