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

Commentary: Hey we think this PR is ready to be merged . If you have some time this week for a quick review , that would be splendid :) 
 The current text lists about 8 reasons for dropping packets . Microsoft 's implementation lists 60 + individual reasons ( via Some of those : LogDrop("Already received server response " ) ; LogDrop("No room for ODCID " ) ; LogDrop("Invalid ODCID " ) ;   failed " ) ;   failed " ) ; LogDrop("Max deferred datagram count reached " ) ; LogDrop("Key no longer accepted " ) ; LogDrop("SH packet during version negotiation " ) ; LogDrop("Too short for HP " ) ; LogDrop("Packet number too big " ) ; LogDrop("Payload length less than encryption tag " ) ; LogDrop("Generate new packet keys " ) ; LogDrop("Decryption failure " ) ; LogDrop("Invalid SH Reserved bits values " ) ; LogDrop("Invalid LH Reserved bits values " ) ; LogDrop("Duplicate packet number " ) ; LogDrop("Key no longer accepted ( batch ) " ) ; LogDrop("Failed to compute HP mask " ) ; LogDrop("Different remote address " ) ; LogDrop("Too small for Packet - Invariant " ) ; LogDrop("LH no room for DestCID " ) ; LogDrop("Zero length DestCID " ) ; LogDrop("LH no room for  " ) ; LogDrop("SH no room for DestCID " ) ;  do n't match " ) ;  do n't match " ) ; LogDrop("Greater than allowed   length " ) ; LogDropWithValue("Invalid client / server packet type " , Packet - LH - Type ) ; LogDrop("Invalid LH FixedBit bits values " ) ;  header has invalid token length " ) ; LogDropWithValue("Long header has token length larger than buffer length " ,  ) ;  header has invalid payload length " ) ; LogDropWithValue("Long header has length larger than buffer length " , LengthVarInt ) ;   does n't have enough room for packet number " , LogDrop("Invalid SH FixedBit bits values " ) ; LogDrop("Non - initial packet not matched with a Connection " ) ; LogDrop("Retry received after initial " ) ; I feel that we do n't need to list things in this level of detail in the qlog spec ( the " trigger " field allows any text anyway ) . However , maybe some guidance text on this would be helpful and maybe a few more suggested triggers would be interesting . 
 Wonder how many reasons Microsoft has for dropping in packets in 2022 . Any input What are your top 20 used reasons ? I think we need to be judiscious with minimizing scope in the qlog document . Unless the triggers are common and self explanatory , we 'll just risk confounding people with options or tying ourselves in knots with text to explain them . Our escape valve is that this is free form text and probably not commonly used for anything special . Being frugal in the base spec is an advantage . 
 fwiw , this is what quic - go has : It seems like many of reasons are just variations of a generic " header parse error " , and could be logged as details to that event . 
 In my experience , if you 're debugging an incident , you need to know the exact line of code , the exact reason why a drop happened , because you need to figure out how to fix it right then . If you only log enough to narrow the scope down to a dozen different code places , that does n't help . I do n't care if there is one field for all the info , or two , with one of them being the " detailed_info " or something , but all the details need to be captured to make it useful . 
 I agree deployments would want the ability to log to that level . Let 's look at HTTP status codes for example . Proxies can fail requests with high level 4xx or 5xx status codes and then use the proxy - status header to include additional data ; namely the parameter . HTTP also has problem details This is effectively a 3 layer model of coarseness - limited top level , broader mid level , very specific low layer . Each of these layers is also well structured , which makes interoperability easier - I.e. grepping out specific cases for alerting or investigation . To map to qlog we could have a limited set of top - level triggers , an optional error type , and a field for detailed info . The last field is likely to be text but in theory you could indicate the format of that text for interop . E.g. , if I want to encode  in event and singal that to consumers explicitly , using a media type could help . But is suspect is probably enough for a lot of folks . 
 just adding a datapoint in favor for being as specific as possible about the reason a packet got dropped on the floor in MVFST we have about 40 different reasons and as says they are useful to identify the specific line of code that drops the packet That being said encoding this information with a generic " Packet Dropped " event and an optional free - form reason / detailed_info field seems like the best course of action to me since it 's not up to qlog specs to define which errors are useful and which ones are less useful . 
 Looking at this , I would agree keeping the list in qlog itself quite short and providing a generic field where implementations can add any type of freeform info they desire . For this , we need 2 things : WHICH of these current triggers on we want to keep ( or do we want to rename / exchange some maybe ? ) . Probably best coming from someone with a large deployment ( a field to the event . I have it as a JSON object instead of a but I do n't mind either way . I 'd put the " error type " in the field as well then feeling that the can act as an " error category " indicator . 
 Looking at our ( currently 79 ) drop reasons in MsQuic , I think the following top - level categories would be reasonable : Internal Error ( not initialized , OOM , etc . ) Rejected ( internal limits reached , ddos protection , unwilling to track more paths , duplicate ) Unsupported ( unknown / unsupported version )   ( packet parsing / validation failed ) Connection Unknown ( CID does n't match ) Decryption Failure ( decrypt failed or key unavailable ) 
 I like Nicks categories . All I might add is a " General " category for anything else , where details can be or not at operator discretion 
 LGTM modulo nits
Paragraph (version A):
This event indicates a QUIC-level packet was dropped after partial or
no parsing.
Paragraph (version A):
Note: sometimes packets are dropped before they can be associated
with a particular connection (e.g., in case of
"unsupported_version").  This situation is discussed more in
handling-unknown-connections.
Paragraph (version A):
Note: for more details on "datagram_id", see transport-datagramssent.
It is only needed when keeping track of packet coalescing.
Paragraph (version B):
This event indicates a QUIC-level packet was dropped.
Paragraph (version B):
The trigger field indicates a general reason category for dropping
the packet, while the details field can contain additional
implementation-specific information.
Paragraph (version B):
unsupported: unknown or unsupported version.  See also handling-
unknown-connections.
Paragraph (version B):
For more details on "datagram_id", see transport-datagramssent.