-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dns cache: add DNS query timeout option #17207
Changes from all commits
baef43e
71de6be
e822fdf
7a2708a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -265,7 +265,9 @@ AppleDnsResolverImpl::PendingResolution::~PendingResolution() { | |
} | ||
} | ||
|
||
void AppleDnsResolverImpl::PendingResolution::cancel() { | ||
void AppleDnsResolverImpl::PendingResolution::cancel(Network::ActiveDnsQuery::CancelReason) { | ||
// TODO(mattklein123): If cancel reason is timeout, do something more aggressive about destroying | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd be inclined to remove the argument if it's not used anywhere, unless you actually plan on following up in the not too distant future. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My intention here was to follow up with at least the Apple DNS provider (and maybe c-ares) to blow away the channels if we have a timeout, to make it more likely we can work around dead connections. cc @junr03 wdyt? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @mattklein123 For the Apple implementation post #17226 there is nothing to blow away as each PendingResolution is getting its own socket (and registered file event with the event loop). On the c-ares implementation, where the connection is shared, the distinction would be useful. A timeout based cancelation could be treated the same as a c-ares error and used to blow up the existing channel. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, let's keep it, and we can make the c-ares change for Android, which I think would be useful IMO. |
||
// and recreating the DNS system to maximize the chance of success in following queries. | ||
ENVOY_LOG(debug, "Cancelling PendingResolution for {}", dns_name_); | ||
ASSERT(owned_); | ||
if (pending_cb_) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make it a bit more clear if the original request is canceled or if we retry in parallel like hedging? I recall (possibly erroneously) that was the latency-improving timeout folks often use on mobile of "if DNS does not return in this time use stale result" which implies to me 5s happens frequently enough we don't want to cancel. Alternately if platform implementation details would result in the OS getting the results for the original request that's Ok too but I'm not sure how to regression test that. cc @RyanTheOptimist @DavidSchinazi for thoughts as this is more their area than mine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this is a good call out. The current implementation will actually cancel and not hedge. Part of the impetus for this change is we think the iOS/apple resolver is occasionally getting wedged, so we are going to accompany this with some changes to that resolver to hopefully make it better handle timeouts (cc @junr03). One thing we might want to do here is actually modify the
cancel()
API to take a reason parameter, so that the impl can do different things if it's a normal cancellation vs. a timeout. I think in the case of timeout we might want to have the impls tare down the DNS connections and make new ones. Let me do that in this change.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "hedge" mean in this context?
I'm not sure about 5s being the right value. I think that's probably too short for a client network stack which need to operate in congested lossy networks. I could look at some telemetry from Chrome around DNS resolution times if that would help? (Of course, I don't know much about the forward proxy deployments so maybe that's the right value for them)
FWIW, the way the stale DNS racing works in Chrome with QUIC is as follows. First host resolution is attempted. If no "Fresh" (presumably cached) result is available but a stale result is (this is all synchronous and does not involve waiting for network events) then the QUIC connection is started using the stale DNS entry. At this point we are running the QUIC handshake in parallel with the DNS request. We only use the resulting QUIC connection to send requests on if the DNS comes back and matches the IP connected to.
To do this, Chrome's resolver basically has two APIs. One for getting a fresh address (which will be async if the address is not cached) and another for getting a stale address (which is always synchronous but may return nothing).
Does that help?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that would be super useful. My feeling though is this is an OK default for server and we can tune it for envoy-mobile config.
Yes definitely. I think this is what we need to move towards. cc @junr03
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm good with the default being server side as long as we make sure that @goaway and @junr03 and co know to tweak their defaults when they pick up the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh and @RyanTheOptimist hedging is an option in router config where you can configure a retry in parallel - 2 requests to 2 upstreams, and cancel the slow one once the first response headers coming back. My point was I was ok with 5s for mobile if we were kicking off a second attempt not canceling the first but I'm also Ok with just upping the default on mobile.