NGTCP2_DEFAULT_HANDSHAKE_TIMEOUT has indeed been deleted last week (but still present in the current latest release 0.13.1): ngtcp2/ngtcp2@edc47d5

The reason being: "current value (10 seconds) is arbitrary choice and no good reason behind it"

But, NGTCP2_ERR_HANDSHAKE_TIMEOUT is an error code with a negative value of -246:
https://github.com/ngtcp2/ngtcp2/blob/8a78123df44e50b64211f8981ef152dde52c8943/lib/includes/ngtcp2/ngtcp2.h#L790

This will silence the compiler error, but it doesn't seem like a useful timeout value.

NGTCP2_DEFAULT_HANDSHAKE_TIMEOUT has indeed be deleted last week (but still present in the current latest release 0.13.1): ngtcp2/ngtcp2@edc47d5

The reason being: "current value (10 seconds) is arbitrary choice and no good reason behind it"

But, NGTCP2_ERR_HANDSHAKE_TIMEOUT is an error code with a negative value of -246: https://github.com/ngtcp2/ngtcp2/blob/8a78123df44e50b64211f8981ef152dde52c8943/lib/includes/ngtcp2/ngtcp2.h#L790

This will silence the compiler error, but it doesn't seem like a useful timeout value.

Building curl with ngtcp2
https://github.com/curl/curl/blob/master/docs/HTTP3.md
as of this link,ngtcp2 will be always latest one and not released one

I think 10 needs to be multiplied by NGTCP2_SECONDS:

#define NGTCP2_SECONDS ((ngtcp2_duration)1000000000ULL)

This restores the existing arbitrary value.

Is there an existing curl timeout that we could re-use here? Like CURLOPT_CONNECTTIMEOUT_MS?

This will become a problem on the next ngtcp2 release either way, so definitely needs to be addressed, ideally before the curl release next week.

I think 10 needs to be multiplied by NGTCP2_SECONDS:

#define NGTCP2_SECONDS ((ngtcp2_duration)1000000000ULL)

This restores the existing arbitrary value.

Is there an existing curl timeout that we could re-use here? Like CURLOPT_CONNECTTIMEOUT_MS?

sorry,i am not sure of this

@tatsuhiro-t any advice?

I propose we provide our own version of the removed define for now. I'm not sure if 10 seconds should be fixed like this, but we can work on that later:

#define QUIC_HANDSHAKE_TIMEOUT (10 * NGTCP2_SECONDS)

QUIC_HANDSHAKE_TIMEOUT: perhaps this could also be re-used across QUIC backends in the future.

It works. If curl has "connect()" timeout, then it can be used here.
Alternatively, just ommit setting handshake_timeout, then QUIC idle timeout will terminate connection during handshake.

then QUIC idle timeout will terminate connection during handshake.

Ah, so how long idleness trigger a termination?

60 seconds.

While pondering if we should perhaps allow for more than 10 seconds and rather use the idle timeout, I propose #10474 which just restores the 10 second handshake timeout but also fixes another necessary change prompted by upstream changes.