An ENDPOINT_ID setup parameter would ease debugging/etc

[TimEvens]

We have a need to identify the endpoint that we are connecting with. Both client and server need to be identified by both ends of the connection. We use this identifier to correlate metrics through all layers of the application. Today we use this ID to build a topology graph (tree of publisher and subscribers) and their path through relays. The ID is also used to inform clients which relay they have connected to, used for troubleshooting/debugs/etc. The IP address or FQDN used to connect to the relay does not identify the actual relay instance connected to when the relay is behind a load balancer and/or anycast.

Example parameter text.

ENDPOINT_ID Parameter

The ENDPOINT_ID parameter (type 0x0x) is an optional setup parameter that identifies the endpoint sending the CLIENT_SETUP or SERVER_SETUP message. The value is a variable length binary byte array that is unique within the application defined scope. The server MUST include an ENDPOINT_ID if CLIENT_SETUP sends it. Servers include the endpoint ID in logs, metrics, and other reporting.

[!NOTE] While endpoint is often identified in the track namespace, it cannot be used by the sever/relay when considering the server/relay does not participate in the encoding scheme. Relays do not have a specific track to identify itself to the client, so the client doesn't know which relay it connects to. Depending on application design, namespace may not uniquely identify a specific endpoint/connection for logging/metrics/tracing/... Relay to relay peering also does not have dedicated tracks for themselves, leaving each relay unaware of which relay instance they are connected.

[ianswett]

I think it's fine to create a parameter like this, but unless there's a use of this ID elsewhere in the draft, it seems very application specific? In general, I'm not excited about having endpoints send any information that isn't clearly actionable by the receiver.

Understanding the topology is interesting, but currently we don't have a metrics collection system in moqt or any other use of such an identifier.

[TimEvens]

@ianswett, Regardless of adding this right now or later, parameter types should be changed to an IANA registry that can then be updated easily with subsequent RFCs that go into details of the entry. The types should have a well known range for development/experimental. The current draft says to ignore unknown parameter types, which is one way to handle this, but it's not ideal when compliance that requires specific types. I suggest having the experimental range that can then be safely ignored.

Adding endpoint_id to this draft saves time in having to write an immediate subsequent RFC to update the IANA registry for endpoint_id. Endpoint is very important for traceability as well as possibility replacing the need for subscribe_id, which I'll write another issue about.

[ianswett]

So it the current issue that our IANA policy about registration of parameters is woefully underspecified? I agree that is an issue and there's a TODO and I believe another issue about that.

[fluffy]

This sounds like it might have some privacy issue.