tracestate response header proposal

One issue that is frequently raised with response headers is the absence of a mechanism similar to tracestate which can be used to return tracing-system-specific information to the caller. As an example, in a multi-tenant tracing system it may be desirable to return the tenant ID with the trace ID and span ID so that the caller knows which tenant to use to look up that trace.

Problem with tracestate response

The primary issue preventing the implementation of a tracestate response header in the past has been the inability to reliably merge tracestate response headers. For example, if node A calls node B and node C which both return a tracestate in the response, how does node A handle conflicts between the tracestate response from B and C if the requests to B and C both return key foo with different values?

Proposal 1 - Do not backpropagate tracestate

Given the above example, node A would not return any tracestate values from the responses from node B or node C. In this case, the support use case described above still works because a customer of A can include A's tracestate response in a support request. A can provide any data in the tracestate it needs in order to look up the trace (cluster id, tenant id, etc).

This is the simplest implementation because the tracestate header can be a completely opaque value. A requester would not receive any tracestate from any of its grandchildren in the trace, but it still opens the possibility for many supportability use cases. A "proxy mode" or similar would also be desired in this case in order for a load balancer, firewall, proxy, or similar system to return the tracestate returned by the target unaltered.

Proposal 2 - Treat tracestate as a set of tokens

Given the above example, treat all tracestate entries as an opaque token (e.g. a=1 is a distinct token from a=2). In this case, node A would concatenate the tracestate responses from B and C, and optionally prepend its own token, then make a pass through the full tracestate which removes all duplicate tokens before including it in the response.

This is slightly more complex to implement as it requires backpropagating the tracestate from children to parent. It would also possibly grow the tracestate quite large, although reasonable limits could be applied. It also raises the question of how to order the tokens from B and C.

Start by reading the two proposed approaches for a tracestate response header and the conflict, propagation, ordering, and size questions described in this issue. Done would require a decided approach for the Trace Context specification, including whether proxy mode or token merging is supported.