<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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>
<br>
<div class="moz-cite-prefix">On 1/19/22 5:25 PM, Dmitry Karpov via
c-ares wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BYAPR01MB56062900E613CF7C7954E7D2C3599@BYAPR01MB5606.prod.exchangelabs.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@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;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</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]-->
<div class="WordSection1">
<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>
<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 class="moz-txt-link-rfc2396E" 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 class="moz-txt-link-rfc2396E" href="mailto:c-ares@lists.haxx.se"><c-ares@lists.haxx.se></a><br>
<b>Cc:</b> Dmitry Karpov <a class="moz-txt-link-rfc2396E" 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>
<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>
<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>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<br>
</body>
</html>