QUIC session/connection state machine invariants

[Wesley Woo]

Hi everyone, I'm looking to add some logic that would allow me to manually trigger the sending of a PING frame on existing QUIC connections.

In my first approach, I created a thread that listened to a local UDP socket and called QuicConnection::SendPing on the reception of a packet to this socket. I ran into a lot of thread affinity errors with this approach.

So in my second approach, I'm trying to repurpose the "keep alive" PING alarm so that it is triggered every 1 ms, and on each trigger checks a flag set by a separate thread to see if it should send a PING frame.

In this second approach, I'm noticing that the PING alarm isn't being triggered consistently -- in a wireshark capture, I can confirm that PING frames are not being sent every 1 ms when the flag is statically set to "send". I also see a delay between when a PING frame is sent and when the flag is set to "send".

Does anyone have any insight into this behavior? I'm guessing there's some sort of invariant preventing PING packets from being sent when the connection is in a certain state?

Thanks!

[Ryan Hamilton]

On Wed, May 8, 2024 at 10:28 AM Wesley Woo <wesley...@gmail.com> wrote:

Hi everyone, I'm looking to add some logic that would allow me to manually trigger the sending of a PING frame on existing QUIC connections.

In my first approach, I created a thread that listened to a local UDP socket and called QuicConnection::SendPing on the reception of a packet to this socket. I ran into a lot of thread affinity errors with this approach.

With very few exceptions, the QUICHE code is single-threaded/not thread-safe. So anything which tries to touch a QuicConnection from multiple threads is problematic.
 

So in my second approach, I'm trying to repurpose the "keep alive" PING alarm so that it is triggered every 1 ms, and on each trigger checks a flag set by a separate thread to see if it should send a PING frame.

This seems more plausible. But you might want to just set your own alarm for this purpose instead of hacking on the existing alarm.

In this second approach, I'm noticing that the PING alarm isn't being triggered consistently -- in a wireshark capture, I can confirm that PING frames are not being sent every 1 ms when the flag is statically set to "send". I also see a delay between when a PING frame is sent and when the flag is set to "send".

PING frames are congestion controlled so depending on how much CWND is available, they may be delayed. They can also be delayed if the writer is write blocked.  You will probably want to look at the logging to see what's going on. That being said, sending lots of PING frames is a very unusual usage pattern. Can you clarify the problem you are trying to solve with PING frames?

Does anyone have any insight into this behavior? I'm guessing there's some sort of invariant preventing PING packets from being sent when the connection is in a certain state?

Thanks!

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/0dfc7eba-92bf-46c9-b9d0-9e431b26a909n%40chromium.org.