Change:
Importance: Base <del> This event indicates a QUIC-level packet was dropped after partial or no parsing. </del> <ins> This event indicates a QUIC-level packet was dropped. The trigger field indicates a general reason category for dropping the packet, while the details field can contain additional implementation-specific information. </ins> Definition: <del> 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. </del> <ins> Some example situations for each of the trigger categories include: </ins> <del> Note: for more details on "datagram_id", see transport-datagramssent. It is only needed when keeping track of packet coalescing. </del> <ins> internal_error: not initialized, out of memory rejected: limits reached, DDoS protection, unwilling to track more paths, duplicate packet unsupported: unknown or unsupported version.  See also handling- unknown-connections. invalid: packet parsing or validation error connection_unknown: packet does not relate to a known connection or Connection ID decryption_failure: decryption key was unavailable, decryption failed general: situations not clearly covered in the other categories For more details on "datagram_id", see transport-datagramssent. </ins> 5.8.

Discussion:
Hey NAME 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 NAME Some of those: LogDrop("Already received server response"); LogDrop("No room for ODCID"); LogDrop("Invalid ODCID"); LogDrop("InitialToken alloc failed"); LogDrop("OrigCID alloc 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 SourceCID"); LogDrop("SH no room for DestCID"); LogDrop("DestCID don't match"); LogDrop("SourceCID don't match"); LogDrop("Greater than allowed max CID length"); LogDropWithValue("Invalid client/server packet type", Packet->LH->Type); LogDrop("Invalid LH FixedBit bits values"); LogDrop("Long header has invalid token length"); LogDropWithValue("Long header has token length larger than buffer length", TokenLengthVarInt); LogDrop("Long header has invalid payload length"); LogDropWithValue("Long header has length larger than buffer length", LengthVarInt); LogDropWithValue("Long Header doesn'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 don'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 NAME 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: URL It seems like many of NAME 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 doesn't help. I don'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 URL; namely the parameter. HTTP also has problem details URL 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 JSON 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 NAME says they are useful to identify the specific line of code that drops the packet URL 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: Decide 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 (NAME NAME NAME Add a field to the event. I have it as a JSON object instead of a but I don't mind either way. I'd put the "error type" in the field as well then NAME 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) Invalid Packet (packet parsing/validation failed) Connection Unknown (CID doesn'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 added or not at operator discretion
LGTM modulo nits