<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle21
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">> Again, there's a reason happy eyeballs doesn't just hammer all endpoints returned from getaddrinfo() simultaneously, I'd think the same reasoning would go for DNS servers ... be kind ... start a second query after a short delay if we
haven't received a response yet (e.g. 200ms). <o:p></o:p></p>
<p class="MsoNormal">> It doesn't make sense to hammer more than 1 DNS server if they're all responsive, you just doubled the network load for DNS for no reason.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">Very true! But in my parallel approach, I didn’t mean to start all parallel queries simultaneously.<br>
I didn’t nail the details, but obviously such approach should be similar to the Happy Eyeballs even for single stacks.<br>
<br>
So, parallel queries in the parallel approach should be started with some small delays like 200ms in Happy Eyeballs, but the whole name resolution should be controlled by one constant and deterministic timeout – i.e. 5s, which shouldn’t depend on the number
of the name servers in the list, as it is currently the case with c-ares.<br>
In my use cases, using c-ares with libcurl, I see different name resolution timeouts: 5s, 15s,… depending on a number of bad name servers in the list, which cause some my time critical services to fail.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">And we can’t just use 200ms as a DNS timeout per name server and iterate name servers sequentially, because there are high-latency satellite links with big RTTs, which require 2s and sometimes more for name resolutions.<o:p></o:p></p>
<p class="MsoNormal">That’s why the parallel approach (with delays between parallel queries) seems to me as a better solution for bad name servers than the sequential one.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">But as I said, any improvements in this area will be very welcomed c-ares extensions, especially if they help libcurl with c-ares, used by a lot of people, to better handle issues with bad name servers.<br>
<br>
Thanks,<br>
Dmitry Karpov<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Brad House <brad@brad-house.com> <br>
<b>Sent:</b> Wednesday, January 19, 2022 2:37 PM<br>
<b>To:</b> c-ares discussions <c-ares@lists.haxx.se><br>
<b>Cc:</b> Dmitry Karpov <dkarpov@roku.com><br>
<b>Subject:</b> Re: Feature request for parallel queries for name servers from different protocol families (IPv4 vs IPv6)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">I guess it always depends on the design of whatever is using c-ares. In my own use cases, I have a single ares_channel running on an event loop and enqueue my lookups to there ... so it keeps state. Nothing
with thread local storage or anything, just dispatching to that event loop for any DNS queries that need to be performed. The single ares_channel can handle multiple simultaneous DNS queries.
<br>
<br>
Also, since there is a proposed feedback loop, if a DNS server is no longer reachable, it will re-sort the list for any future requests, so it would only impact a single request (ok, well, whatever number of requests came in before the timeout or error occurred).<br>
<br>
Again, there's a reason happy eyeballs doesn't just hammer all endpoints returned from getaddrinfo() simultaneously, I'd think the same reasoning would go for DNS servers ... be kind ... start a second query after a short delay if we haven't received a response
yet (e.g. 200ms). It doesn't make sense to hammer more than 1 DNS server if they're all responsive, you just doubled the network load for DNS for no reason.<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 1/19/22 5:25 PM, Dmitry Karpov via c-ares wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">> I wasn't suggesting this be outside of c-ares, I was talking about implementing this inside of c-ares as a simpler alternative to your proposal.<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">OK, I got it know. :) <br>
Pre-sorting name servers based on reachability from previous queries or/and protocol family may help in some cases, but the sequential approach, even with sorting, still will have some issues that the parallel approach allows to solve more efficiently.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">For example, the first query when nothing is sorted, may cause critical connection timeouts aborting some applications, and storing name server “reachability metrics” which name servers will be sorted on will require either thread local
storage (thus requiring each thread to go through the same “name server discovery” procedure as the other app threads using c-ares) or some global access to the metrics data with proper read/write accesses, needed by multi-threaded apps.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Also, if run-time conditions change from the previous query then the sorted list may be not sorted correctly for the current conditions, and thus not the best server or even bad server may be tried first, thus increasing name resolution
time.<br>
<br>
The parallel approach, on the other hand, will provide the fastest name resolution regardless the previous queries, so it doesn’t need to store any name server metrics and do pre-processing of the name server list from OS.<o:p></o:p></p>
<p class="MsoNormal"><br>
But I agree that implementing parallel approach may be not very easy and any improvements in this area will be a very welcomed extension, anyway.<br>
So, if you think that updated sequential approach with smart sorting is much easier to implement than the parallel one, then hopefully we can get it in next c-ares updates.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks,<br>
Dmitry Karpov<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Brad House <a href="mailto:brad@brad-house.com">
<brad@brad-house.com></a> <br>
<b>Sent:</b> Wednesday, January 19, 2022 12:10 PM<br>
<b>To:</b> c-ares discussions <a href="mailto:c-ares@lists.haxx.se"><c-ares@lists.haxx.se></a><br>
<b>Cc:</b> Dmitry Karpov <a href="mailto:dkarpov@roku.com"><dkarpov@roku.com></a><br>
<b>Subject:</b> Re: Feature request for parallel queries for name servers from different protocol families (IPv4 vs IPv6)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Commenting below ...<o:p></o:p></p>
<div>
<p class="MsoNormal">On 1/19/22 2:51 PM, Dmitry Karpov via c-ares wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">> Infact, happyeyeballs itself doesn't always do parallel connection attempts, its an implementation-defined delay before also attempting the next address in the list.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">In case of Happy Eyeballs, a delay between IPv4 and IPv6 connections is constant and typically relatively short – 200-300ms.<br>
But non-functional IPv6 name servers in the server list may create dynamic delays in connection establishment which can be very large.<br>
<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">By default, c-ares uses 5s timeout per name server, so it may take 5s and more (if several IPv6 name servers are in the list) to get to the connection Happy Eyeballs thus taking
much more than expected 200-300ms.<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><br>
It would be assumed as part of this patch set, this timer would be reduced.<br>
<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
> It would be much easier to stay closer to happy eyeballs and just sort the dns server list using prior result success/fail (even upfront sorting using some algorithm to interleave ipv6/ipv4 in a pattern would help,
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">> maybe with using logic such as from RFC6724 sec 2.1 like we do in ares_getaddrinfo for returned addresses, but instead of the nameservers themselves).
<br>
<br>
Yes, of course, it is possible that c-ares client can implement some kind of name server sorting/filtering logic outside of c-ares and just pass a list of “good” name servers to c-ares, but in this case it has to be more involved into the name resolution business
than it would be desired.<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><br>
I wasn't suggesting this be outside of c-ares, I was talking about implementing this inside of c-ares as a simpler alternative to your proposal.<br>
<br>
-Brad<o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>