build error due to change in ngtcp2 variables

[Karthikdasari0423]

raised PR cause while build curl with ngtcp2 below error is noticed
#10468

hers is the PR to ngtcp2 which is causing issue
ngtcp2/ngtcp2#665

[vszakats]

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.

[Karthikdasari0423]

--handshake-timeout=
Set the QUIC handshake timeout.
Default: 10s

[Karthikdasari0423]

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

[vszakats]

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?

[vszakats]

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.

[Karthikdasari0423]

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

[bagder]

@tatsuhiro-t any advice?

[bagder]

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)

[vszakats]

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

[tatsuhiro-t]

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.

[bagder]

then QUIC idle timeout will terminate connection during handshake.

Ah, so how long idleness trigger a termination?

[tatsuhiro-t]

curl/lib/vquic/curl_ngtcp2.c

Line 92 in ca95d39

#define QUIC_IDLE_TIMEOUT (60*NGTCP2_SECONDS)

curl/lib/vquic/curl_ngtcp2.c

Line 244 in ca95d39

t->max_idle_timeout = QUIC_IDLE_TIMEOUT;

60 seconds.

[bagder]

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.