Trace Context Extensibility about trace-context HOT 7 OPEN

Proposal 4: Trace State for new persistent fields

tracestate format is a set of key-value pairs. It looks like this: k1=v1,k2=v2. tracestate entries unknown to a trace participant are typically propagated unchanged unless the list becomes too long, or a participant decides not to forward the header for performance reasons. Propagating tracestate is optional, but in practice it is done by most tracing participants.

This opens up the possibility to use tracestate to propagate fields that should survive the whole trace. One example of such a field might be the sampling selectivity of the head of the trace. Any trace participant which is not updated to the new standard should still propagate the value unchanged. It would be possible to either use a single field for multiple cases, multiple fields, or reserve a whole vendor key namespace for future use.

Advantages:

• This is already the behavior of existing implementations, meaning new fields could be used immediately without fear of being dropped (usually).

Concerns:

• Currently there are no reserved tracestate keys. This would require reserving keys, which is technically a breaking change. Work would need to be done to ensure any reserved keys are not already in use.
• This would require any trace participant looking to introduce one of these fields to use 2 headers. In many cases it is possible and even likely that there is no existing tracestate header, so this would require adding a full new header for these cases.

Proposal 4 part 2: combine proposal 4 and 1

This is similar to (3) however instead of new fields in the traceparent header it uses new fields in tracestate if they are required to be persisted for the whole trace. It has similar advantages to 3 and 4. See those proposals for details.

Proposal 5: do nothing

This is here for completeness, however I do not feel we should take this option. We do have the option to do nothing, and to rely on the semantics we already have. This would mean new flags or fields that should be persisted for the whole trace (like the random flag) require all trace participants to be updated before it can be assured that the flag or field is persisted. Flags and fields which only describe a single trace participant would work fine in this scenario.

from trace-context.

how about Proposal 0: rollback the rule "it is required to set those flags to 0". It was clearly an oversight, and while rolling it back does not solve the immediate problem, it future-proofs the spec.

from trace-context.

Proposal 0: Roll back set-0 requirement

This proposal is to roll back the rule requiring unknown flags to be set to 0. It would require that all unknown flags are propagated unchanged. The primary disadvantage of this proposal is that some flags may describe only a single participant in the trace, not the whole trace. In this case, it is possible to propagate a false claim. For example, a flag which indicates that the parent participant is a browser client. Take a trace with 3 participants A -> B -> C where A and C are updated but B is not. If A sets the browser flag, B will propagate it to C causing C to incorrectly interpret its parent as a browser.

from trace-context.

The primary disadvantage of this proposal is that some flags may describe only a single participant in the trace, not the whole trace.

My argument would be that this is a false use case. This refers to information that only makes sense in a single hop, which can be sent via multitude of other ways, not via trace context that is meant to make sense across the whole distributed workflow (and therefore is optimized for repeated transmission, whereas one-hop data can afford to spend a few more bytes). You would have the same problem if we did not have bitmap in the context at all and you tried to send this "I am a browser" signal via tracestate - it would also be incorrectly propagated throughout, because again the mechanism is not designed for one-hop data.

from trace-context.

The sampling bit is an example of this. It is propagated, but it is meant to describe only the parent. It could be flipped to 0 if one participant decided to prune its branch of the trace for some reason.

from trace-context.

Question: can anyone think of a bit that would be harmful if propagated through the full trace by out-of-date participants?

from trace-context.

Thanks @dyladan for putting together this summary! Here are my current thoughts/questions:

1. Regarding the discussion on Proposal 0, I see two potential concerns:

• Wouldn't that option imply a breaking change on an official W3C recommendation spec?
• Sampling flag is a good example of a flag that fits in the traceparent header (even if it is for single hop validity), I am not sure if we want to close the door on not having such situations in the future.

2. Regarding Proposal 4, I like the aspect that it is already a solution that can take effect right away (rather than waiting ~5 years for all current implementations to update to a newer version of tracecontext). A couple of questions here:

• Is it a must to register any prefix here, or can we do this on demand depending on any use case that emerges? Since we have this registry https://w3c.github.io/tracestate-ids-registry/, I feel there's a good handle on who are all using tracestate.
• Regarding the overhead of the new header, in the fullness of time, as more vendors (including new OTel samplers) start using it, wouldn't the cost of this header be amortized?

from trace-context.