Draft: draft-ietf-quic-qlog-quic-events

Commentary: asked how to best approach logging from a server 's perspective , given that things like version negotiation and stateless retry are not inherently tied to a single connection . We should add some informative guidance on how to best approach this to the spec , depending on how much state you 're willing to keep around Some options : state : keep a separate qlog file for the entire server . This logs vneg , retry , etc .. Then , when a connection is truly accepted , start a new .qlog for the individual connection , containing all events thereafter . The can then also contain an event signalling the acceptance of a new connection for later cross - linking between the files . state : keep a single huge qlog file for everything , using the " groupid " field to allow later de - multiplexing into separate connections ( I believe quant does this atm ) : if you already track vneg / retry and link them up with the final connection , you can output them in the per - connection qlog file as well Maybe also shortly talk about some of the trade - offs in each option . Also talk about how to approach server - level events like serverlistening and packet_dropped in separate scenarios . 
 I lean on the side of minimally and clearly identifying the challenges and maybe signpost some features and leave it up to implementers to figure out how to address this . They can always push back later in the specification lifecycle is something is deemed missing .
Paragraph (version A):
For several types of events, it is sometimes impossible to tie them
to a specific conceptual QUIC connection (e.g., a packet_dropped
event triggered because the packet has an unknown connection_id in
the header).  Since qlog events in a trace are typically associated
with a single connection, it is unclear how to log these events.
Paragraph (version A):
Ideally, implementers SHOULD create a separate, individual "endpoint-
level" trace file (or group_id value), not associated with a specific
connection (for example a "server.qlog" or group_id = "client"), and
log all events that do not belong to a single connection to this
grouping trace.  However, this is not always practical, depending on
the implementation.  Because the semantics of most of these events
are well-defined in the protocols and because they are difficult to
mis-interpret as belonging to a connection, implementers MAY choose
to log events not belonging to a particular connection in any other
trace, even those strongly associated with a single connection.
Paragraph (version A):
Note that this can make it difficult to match logs from different
vantage points with each other.  For example, from the client side,
it is easy to log connections with version negotiation or retry in
the same trace, while on the server they would most likely be logged
in separate traces.  Servers can take extra efforts (and keep
additional state) to keep these events combined in a single trace
however (for example by also matching connections on their four-tuple
instead of just the connection ID).
Paragraph (version B):
A single qlog event trace is typically associated with a single QUIC
connection.  However, for several types of events (for example, a
transport-packetdropped event with trigger value of
"connection_unknown"), it can be impossible to tie them to a specific
QUIC connection, especially on the server.
Paragraph (version B):
Log them in a separate endpoint-wide trace (or use a special
group_id value) not associated with a single connection.
Paragraph (version B):
Log them in the most recently used trace.
Paragraph (version B):
Use additional heuristics for connection identification (for
example use the four-tuple in addition to the Connection ID).
Paragraph (version B):
Buffer events until they can be assigned to a connection (for
example for version negotiation and retry events).