Clarify b3 debug flag and parent span id handling

[mwear]

Fixes #1004

Changes

This PR clarifies how OpenTelemetry should handle the B3 debug trace flag and parent span id propagation.

As discussed in issue #1004, OpenTelemetry does not support client and server spans sharing an id when they are part of the same request. To enable this, B3 support propagating a parent span id, in addition to the current span id. As a result, OpenTelemetry safely ignore the parent span id when propagating B3.

When receiving a B3 debug trace flag, an OpenTelemetry implementation should preserve and propagate the debug trace flag, but internally treat it as a sampled trace flag.

See https://github.com/openzipkin/b3-propagation for more details.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[carlosalberto]

@open-telemetry/specs-approvers Please review this PR, as it's gone stale given the lack of reviews. Observe that at this moment is basically mentions the current state of B3 Propagators in our implementations.

[arminru]

The PR looks reasonable but I don't know B3 and cannot assess the implications of this.
Do we have any reviewer that's more familiar with B3 that we can ping besides you, @carlosalberto?

[anuraaga]

This seems fine to me, if we decide to support propagating span ID in the future, it would be a backwards compatible spec change.

[Oberon00]

Would #881 help with handling the debug flag better? You could store it in the Context then and the sampler would receive it.

[carlosalberto]

@Oberon00 I think it could definitely help, also adding it is probably a post-GA task at this point.

[Oberon00]

To clarify: You mean both this PR and #881 should be OK for GA, but a more advanced debug flag handling for B3 based on #881 would be after-ga, right?

[carlosalberto]

@Oberon00 Yes :)

[tedsuo]

This looks good to me. As a hedge, at some point we could get the Zipkin community to review the B3 portion of our spec, to make sure we didn't miss something.

[mwear]

This looks good to me. As a hedge, at some point we could get the Zipkin community to review the B3 portion of our spec, to make sure we didn't miss something.

My guess is that the Zipkin community will request that we propagate ParentSpanID to support client and server spans sharing the same span id. We should get their input to understand what the potential side effects are for not propagating it.

[carlosalberto]

Merging as there are enough approvals, this PR has been standing for a while, and it also clarifies what we already have now in most of the implementations.

[jkwatson]

do we have instructions on how we're supposed to propagate the debug flag, exactly? Is this something that the propagator needs to put into the Context?

[Oberon00]

See #1045 (comment) and #1045 (comment): I guess so, yes.

[jkwatson]

See #1045 (comment) and #1045 (comment): I guess so, yes.

Hmm. implementation recommendations in hidden comments probably aren't the best way to communicate them. ;)

[Oberon00]

@mwear said

I purposely left this ambiguous because it's an implementation detail

But I guess a non-normative note would indeed be helpful here.

[jkwatson]

@mwear said

I purposely left this ambiguous because it's an implementation detail

But I guess a non-normative note would indeed be helpful here.

Should this be an implementation detail, @mwear ? Is there some other way in OTel for information to be propagated that I'm not aware of? Isn't the context the only way that propagators can possibly propagate this data?