rmarx
commented
4 years ago In draft-01, we made the conscious choice to limit the number of events as much as possible and make most event data based on the Frame definitions that already existed for packet_sent and packet_received. Combined with proper naming of properties (e.g., packet_type instead of type) this enables fast parsing while removing the need for separate events for each possible signal.
For example: PACKET_RECEIVED vs 1RTT_PACKET_RECEIVED FRAME_NEW vs ACK_FRAME_NEW
For the leftmost entries, one would add a "type" field to the "DATA" value, e.g.,
The shorter form makes that we have a much less large amount of different EVENT_TYPEs, but also makes it a bit harder to parse for human readers + harder to quickly filter for tools. The longer form is much more explicit, but requires much more definition up-front and a proliferation of different EVENT_TYPEs.
We could also break consistency. i.e., the original qlog used PACKET_RECEIVED with an explicit type in the DATA, but used ACK_FRAME_NEW for individual frames.
Currently, we use the short-form, since this is most similar to quic-trace and keeps it consistent if we want to log frames both in their own events and again when sending a packet.
Extra edge-case: Errors If you go for extreme short-form, you would just have a single ERROR EVENT_TYPE for each CATEGORY, and define the error type in the DATA. However, for easier manual debugging, tracking the specific type of error directly in the EVENT_TYPE is arguably easier. Maybe an exception should be made for errors?