Re: Question about upcoming "asyn-ares: connect async" change in 8.20

> Am 16.04.2026 um 21:40 schrieb Dmitry Karpov <[email protected]>:
> 
> Hi Stefan,
> 
> Thanks for explanations! Now, the direction is clearer, but I think one thing is still worth further discussion.
> 
> The Happy Eyeballs v3 proposal document mentions the "resolution time delay":
> 
>>> 
> 4.2. Handling DNS Answers Asynchronously
> ...
> The client moves onto sorting addresses and establishing connections once one of the following condition sets is met:
> 
> Either:
>    Some positive (non-empty) address answers have been received AND
>    A positive (non-empty) or negative (empty) answer has been received for the preferred address family that was queried AND
>    SVCB/HTTPS service information has been received (or has received a negative response)
> 
> Or:
>    Some positive (non-empty) address answers have been received AND
>    A resolution time delay has passed after which other answers have not been received.
> ...
> 
> The resolution time delay is a short time that provides a chance to receive preferred addresses (via AAAA records) along with service information (via SVCB/HTTPS records). 
> This accounts for the case where the AAAA or SVCB/HTTPS records follow the A records by a few milliseconds. This delay is referred to as the "Resolution Delay".
> 
> The RECOMMENDED value for the Resolution Delay is 50 milliseconds.

This is an aspect we have not implemented yet. I see your point in regard to AAAA addresses. curl always treated them as the preferred address family. I am hesitant to implement the 50ms delay for HTTPS records right now since they are still rare.

My next iteration will most likely be:
- if a AAAA answer has been received (positive or negative), continue connecting.
- without AAAA answer, wait the 50ms before continuing.

>>> 
> 
> As far as I understand it, the "Resolution Delay" is a waiting period, which directs the client to wait for the preferred family DNS response (IPv6) before trying to
> make a connection attempt on a not-preferred one (IPv4) in cases when A response came earlier.
> 
> If so, then I guess it becomes a new "Happy Eyeballs timeout" value and thus will probably be controlled by CURLOPT_HAPPY_EYEBALLS_TIMEOUT_MS option.
> Am I right, or the "Happy Eyeballs timeout" will have a different meaning than the "Resolution Delay"?

The happy eyeball timeout setting has the same semantics as before, spacing the different connect attempts.

> 
> I am asking because it is not clear what is the meaning of the "Happy Eyeballs timeout"(HET) with the new approach, as connection attempts now
> may start immediately upon receiving DNS response and without waiting for HET to expiry.
> 
> I have some concerns about it because I have seen network configurations when AAAA responses may come later than A responses, but it was worth waiting
> because IPv6 connections were still faster, and I am afraid that the new mechanism may favor IPv4 connectivity more than before, unless client is provided a mechanism
> to tune the "Resolution Delay" and give more slack to IPv6.
> 
> Thanks,
> Dmitry
> 
> -----Original Message-----
> From: Stefan Eissing <[email protected]> 
> Sent: Wednesday, April 15, 2026 11:50 PM
> To: libcurl development <[email protected]>
> Cc: Dmitry Karpov <[email protected]>
> Subject: [EXTERNAL] Re: Question about upcoming "asyn-ares: connect async" change in 8.20
> 
> Hi,
> 
>> Am 16.04.2026 um 00:25 schrieb Dmitry Karpov via curl-library <[email protected]>:
>> 
>> Hi All,
>> 
>> I have a question about the "asyn-ares: connect async" change (https://github.com/curl/curl/pull/21205) in the upcoming 8.20 release.
>> 
>> The PR description says:
>> "This PR updates the async DNS resolver behavior (notably the c-ares backend) to issue separate A and AAAA queries and make partial DNS information available earlier, enabling connection attempts to begin as soon as the first relevant DNS response arrives."
>> 
>> I am wondering how this new behavior will affect the Happy Eyeballs for dual-stack?
>> 
>> For example, if the A query result is received earlier than the AAAA query one, does it mean that IPv4 connect attempts will start before IPv6 ones?
> 
> Yes.
> 
>> Or IPv4 will still have to wait in this case until the HEB timeout expires?
> 
> No, the intent of splitting the query is to react to the first incoming response.
> 
>> Also, it seems that this change makes it possible to go with a slower IPv4 connection if A response comes faster than AAAA response.
>> 
>> Before this change, the dual-stack race was just between connections, 
>> and the fastest would win, but now as DNS replies are also part of the "stack" race, it seems possible that a slower stack connection may win if it's DNS reply comes faster.
>> 
>> It would be helpful to get some clarifications how the Happy Eyeballs mechanism will work with this change.
> 
> The intent of the changes (and there will be more coming) is to follow the Happy Eyeballs v3 proposal (https://www.ietf.org/archive/id/draft-ietf-happy-happyeyeballs-v3-01.html), at least to an extent that the curl team considers reasonable.
> 
> Cheers,
> Stefan
> 
>> 
>> Thanks,
>> Dmitry Karpov
>> 
>> --
>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>> Etiquette:   https://curl.se/mail/etiquette.html
> 

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html