Opened 19 months ago

Closed 18 months ago

#2492 closed defect (invalid)

QUIC：The quic connection was not closed, when max_idle_timeout arrived.

Reported by: bullerdu@… Owned by:
Priority: minor Milestone:
Component: http/3 Version: 1.23.x
Keywords: quic Cc:
uname -a: Linux dev.na61 4.19.91-008.x86_64 #1 SMP Fri Sep 4 17:33:26 CST 2020 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.23.4
built by gcc 9.3.0 (GCC)
built with OpenSSL 1.1.0 (compatible; BoringSSL) (running with BoringSSL)
TLS SNI support enabled
configure arguments: --with-debug --with-http_v3_module --prefix=/home/yefei.dyf/nginx --with-cc-opt=-I/home/yefei.dyf/boringssl/include --with-ld-opt='-L/home/yefei.dyf/boringssl/ssl -L/home/yefei.dyf/boringssl/crypto'

Description (last modified by Sergey Kandaurov)

The triggering logic was as follows:

  1. The quic connection was terminated by ngx_quic_close_connection(c, NGX_OK), then set qc->close event to three times PTO timer.
  2. The c->read event was set max_idle_timeout timer.
  3. When c->read was timeout, call ngx_quic_close_connection(c, NGX_DONE), but the quic connection was not close for waiting qc->close timer.

Change History (3)

comment:1 by Sergey Kandaurov, 18 months ago

Description: modified (diff)

I do not see a problem there, can you elaborate?

In particular:

  • idle timeout is expected to be way longer than three times PTO.
  • even if idle timeout is still happens before three times PTO as set by close handler, it waits for close timer to expire
  • RFC 9000, 10.1 has a related statement regarding idle timeout vs. PTO: 
    To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO). This allows for multiple PTOs to expire,
and therefore multiple probes to be sent and lost, prior to idle
timeout.

in reply to:  1 comment:2 by bullerdu@…, 18 months ago

Replying to Sergey Kandaurov:

I do not see a problem there, can you elaborate?

In particular:

  • idle timeout is expected to be way longer than three times PTO.
  • even if idle timeout is still happens before three times PTO as set by close handler, it waits for close timer to expire
  • RFC 9000, 10.1 has a related statement regarding idle timeout vs. PTO: 
    To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO). This allows for multiple PTOs to expire,
and therefore multiple probes to be sent and lost, prior to idle
timeout.

OK, Thanks for the rfc9000 details from you.

In my case, the pto time was tens of seconds calculated by ngx_quic_pto, and the max_idle_timeout was less than three times the pto time.

According to the RFC description, this situation meets the criteria.

Version 0, edited 18 months ago by bullerdu@… (next)

comment:3 by Sergey Kandaurov, 18 months ago

Resolution: → invalid
Status: new → closed

Tens of seconds looks quite high to be normal.
Anyway, thanks for confirming, closing this ticket.

Note: See TracTickets for help on using tickets.