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

Commentary: rebase on main should fix the cddl tests 
 Currently , we have a mechanism for tracking QUIC packet coalescing in a single UDP datagram by means of the field . This was originally as per . Main intended use : when a UDP payload is received containing multiple coalesced QUIC packets , those QUIC packets are given the same " datagram ID " ( which is a receiver - side chosen number that 's unique per received datagram , which is needed because UDP datagrams do n't have a packet number or similar ) . As such , when 2 separate packets are logged in 2 separate events , but they have the same value for the field , it 's clear they were coalesced . Similarly , 2 events with the same indicate sender - side coalescing . As the original issue indicates , this can be deduced from the events as well , but those are often too chatty to leave on . The fields on the events are for completeness / ability to track coalesced packets across the different events . I 'm personally not the biggest fan of this solution ( did you eventually implement this in quic - go , but I do n't immediately see a better approach . CC as he indicated the use of was n't clear to him , which means we either need to revisit or clarify its use . 
 I 'll try to summarise my understanding . The is specified for the following events packetsent packetreceived packetbuffered packetdropped datagramssent ( an array here , but same purpose ) datagramsreceived ( an array here , but same purpose ) The use of the ID is given in and currently says : I do n't mind the motivating use case . I 'm not sure exactly how my implementations could use it for packet sending events because we generate the packet and qlog it before we get into UDP datagram realms . Changes might address that but I 'm not sure it 's worth overhead . Other implementations might find it far more natural to use though . The main part I find confusing is the part about . This is vague and quite specific at the same time . How unique does something need to be ? Can I just use a counter like datagramid = 0 , datagramid=1 for the packets sent on a connection ? Or is the expectation that the identifier is more like a UUID , so that packets are uniquely traceable ? Maybe it depends if we are capturing single connections or traces that span mutliple things , so perhaps a reword to state the requirements and expectations of the datagramid value could help . E.g. " Since QUIC traces may contain many UDP events , unique identifiers are required for each datagram in order to avoid them being confused . Identifiers are not exchanged on the wire , they are only relevant to the logging endpoint . Selecting identifier values is left to implementations that should consider how to generate unique values within the scope of the traces they generate " 
 LGTM modulo nit
Paragraph (version A):
The "datagram_id" is a qlog-specific concept to allow tracking of
QUIC packet coalescing inside UDP datagrams.  Since QUIC generates
many UDP datagrams, unique identifiers are required to be able to
track them individually in qlog traces.  However, neither UDP nor
QUIC exchanges datagram identifiers on the wire.  Selecting
identifier is values is thus left to qlog implementations, that
should consider how to generate unique values within the scope of
their created traces.
Paragraph (version B):
The "datagram_id" is a qlog-specific concept to allow tracking of
QUIC packet coalescing inside UDP datagrams.  Since QUIC generates
many UDP datagrams, unique identifiers are required to be able to
track them individually in qlog traces.  However, neither UDP nor
QUIC exchanges datagram identifiers on the wire.  Selecting
identifier values is thus left to qlog implementations, which should
consider how to generate unique values within the scope of their
created traces.