Observed rarely as "connection idle timed out" in various Http3 tests.

Caused by an unexpected interaction between the packet transmission task and the pacer.

When the transmission is blocked by the pacer, the next deadline (twoPacketDeadline) is based on the deadline when the pacer was last updated, the number of quota bytes required, and the pacing rate. If the pacing rate is high enough, the next deadline will be less than 1 nanosecond away, rounded down to equal the last update.

When the packet transmission task detects that the next deadline is not in the future, it loops without updating the current deadline, or the pacer. Since the pacer is not updated, it does not permit sending any additional data, and the loop continues forever without making any progress.

The packet transmission task doesn't update the deadline for historical reasons. Originally the task was run on the selector thread, and was cooperatively scheduled with other tasks running on the same thread. It was important that the task finishes in a reasonable time, and lets other tasks run.
Today, the task is running on its own thread, so there's no reason why it shouldn't update the current deadline or the pacer.