Should QUIC provides PING interface for upper layer?

[K9A2]

As we know, HTTP/2 provides PING frame and corresponding PING acks, to fetch the application-layer delay. But HTTP/3 states "PING frames do not exist, since QUIC provides equivalent functionality", while QUIC only sends a PING frame to check the reachability of its peer without delay calculation.

The other way of fetching QUIC-layer delay is extracting from the congestion control module. But the application can only read dealy info when there is some data to send. It can not send a probe proactively.

Should QUIC provides a similar interface to fetch such a application-delay?

[DavidSchinazi]

HTTP/2 PING frames exist to measure the round-trip delay, they're not specific to application-layer delay. QUIC blurs the layers in such a way that I don't think there is an actual difference between application-layer delay and network-layer delay. (Not that the OSI model ever made sense, but that's another conversation...) The combination of QUIC PING and ACK frames allow you to calculate the round-trip delay in a way that's even more accurate because the ACK frame carries an ACK Delay field that allows you to compute on-device delay. Could you clarify what exactly it is that QUIC does not allow to measure today?

[MikeBishop]

A QUIC implementation can provide a feature to trigger a PING frame and optionally check the time until it gets ACK'd. I don't think that's something the specification needs to require, because it's not required for interoperability, but it's certainly a capability that market pressure might drive an implementation to expose.

[K9A2]

Actually, I am doing some research on H3 request schedule mechanism using HTTP/3 connection level delay partly. Yet neither the spec of H3 nor QUIC provides an interface to fetch delay from H3 connection or QUIC connection. Workarounds do exists, if I use ICMP PING Frame, or calculate TTFB when I send H3 request as result, or get it directly from QUIC congestion control module. But none of these workarounds fit my purpose on pro-actively retrieving the dealy of H3 connection or QUIC connection. At last, I end up implementing by pro-actively send QUIC PING Frame and wait my peer
acknowledges the QUIC packet contains it.

I found another research doing the similar thing as I do. Their paper is "MP-H2: A Client-only Multipath Solution for HTTP/2". They just use the H2 PING and corresponding ack to get H2-level delay.

This is all I am thinking about.

[LPardue]

I'm not seeing the issue here.

The QUIC transport provides the capability to send PING and measure the time until it is ACK'd. It seems like you are using this and it works for you?

The HTTP/3 mapping can use all transport features, it doesn't need to redefine them. So as Mike says, the discussion becomes one about implementation API and how an HTTP/3 implementation might choose to expose transport layer features. That is not something the QUIC WG needs to consider in the specification(s) IMO.

[K9A2]

Thanks for the comments from @DavidSchinazi, @MikeBishop, @LPardue, and @agrover. It seems that I have think too much on what QUIC spec shoud do. I am going to close this issue, and open seperate issue on QUIC implementations to request such feature.