RFR: 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout [v4]

[Jaikiran Pai]

> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
> 
> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
> 
> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
> 
> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
> 
> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those request/responses would ...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove unwanted file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28522/files
  - new: https://git.openjdk.org/jdk/pull/28522/files/b3b73048..0e55e4a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=02-03

  Stats: 29 lines in 1 file changed: 0 ins; 29 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28522/head:pull/28522

PR: https://git.openjdk.org/jdk/pull/28522