You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we re-use the RawInfo struct to give a simple re-usable way to log raw packet/frame/datagram contents.
In the struct, we have two length-fields: the full length and payload_length, assuming the header length can be calculated from those two.
However, we do not have a way to log e.g., only the payload without the header (we can only log the full value truncated, but not indicate it starts at the payload).
This isn't a problem for QUIC/H3 packets/frames, but as @jlaine pointed out, it is a problem for UDP datagrams. In most stacks, you don't get the pure UDP packet header and so can't log it (so you'd always start with the payload).
This can be solved in several different ways:
disallow usage of RawInfo for datagrams
make explicit that datagram-related events start at the payload
log a fixed-value/fixed-size dummy UDP datagram (e.g., 8 bytes of zeroes)
extend RawInfo to make it more flexible
I'm currently most in favor of 2, as I don't see many people logging full UDP datagrams instead of logging the QUIC packets.
The text was updated successfully, but these errors were encountered:
Currently, we re-use the RawInfo struct to give a simple re-usable way to log raw packet/frame/datagram contents.
In the struct, we have two length-fields: the full
length
andpayload_length
, assuming the header length can be calculated from those two.However, we do not have a way to log e.g., only the payload without the header (we can only log the full value truncated, but not indicate it starts at the payload).
This isn't a problem for QUIC/H3 packets/frames, but as @jlaine pointed out, it is a problem for UDP datagrams. In most stacks, you don't get the pure UDP packet header and so can't log it (so you'd always start with the payload).
This can be solved in several different ways:
I'm currently most in favor of 2, as I don't see many people logging full UDP datagrams instead of logging the QUIC packets.
The text was updated successfully, but these errors were encountered: