Figure out how to map QUIC to network.* attributes

[antonfirsov]

Area(s)

network

Is your change request related to a problem? Please describe.

Edit: #1237 (comment)

Today it's not clear what network.* attributes should be assigned to what values when using QUIC or Unix Domain Sockets.

The attribute spec links to OSI definitions which do not list these protocols, and in fact these protocols do not map well to OSI concepts.
https://osi-model.com/network-layer/
https://osi-model.com/transport-layer/

#389 recommends mapping network.transport=quic for QUIC, which is not really accurate if we take OSI literally. I believe this is a source of confusion. The spec should provide explicit recommendations to help determine attribute choices for protocols that do not map well to OSI.

Describe the solution you'd like

After making a decision, make sure that quic and uds are listed as well-known values in the spec, making it clear what should be used.

Describe alternatives you've considered

No response

Additional context

No response

[antonfirsov]

Sorry, missed that there is network.transport = unix for UDS already. QUIC still needs clarification.

[lmolkova]

I don't see any controversy in network.transport=quic ("QUIC (/kwɪk/) is a general-purpose[1] transport layer[2] network protocol")

Do you feel we need to mention it explicitly?

[antonfirsov]

So there are two different protocols in the same OSI layer while network.transport needs us to pick only one without defining a criteria. #1239 will make things clearer IMO!

[JamesNK]

QUIC is built on top of UDP. Is that a conflict?

[lmolkova]

QUIC is built on top of UDP. Is that a conflict?

@JamesNK
it's defined as a transport protocol - using quic would be more precise than using udp. I.e. if we record quic as udp we'd lose some information, but if we record it as quic we won't lose anything. So from my perspective there is no conflict.