You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today qlog has packet_sent events and datagrams_sent events, which can be used to log the event and the time it occurred.
In some scenarios, the application generating packets or even datagrams is not in direct control of the emission of those packets to the wire. For example, a QUIC library may be called to generate a batch of packets that are intended to be sent out on a future time schedule. If the pacing is offloaded to some other component, such as the kernel, then reporting events in a qlog might be practically hard.
Something we've done in quiche is to add an additional send_at_time field in the packet_sent event. This contains a timestamp that the QUIC layer decided that the packet should be sent out at. We can keep that as custom extension but I was curious if others had any opinions.
The text was updated successfully, but these errors were encountered:
Today qlog has packet_sent events and datagrams_sent events, which can be used to log the event and the time it occurred.
In some scenarios, the application generating packets or even datagrams is not in direct control of the emission of those packets to the wire. For example, a QUIC library may be called to generate a batch of packets that are intended to be sent out on a future time schedule. If the pacing is offloaded to some other component, such as the kernel, then reporting events in a qlog might be practically hard.
Something we've done in quiche is to add an additional
send_at_time
field in the packet_sent event. This contains a timestamp that the QUIC layer decided that the packet should be sent out at. We can keep that as custom extension but I was curious if others had any opinions.The text was updated successfully, but these errors were encountered: