Option to allow "default" IDs for unsampled traces

[awssandra]

Follow-up from the Sampling SIG on 08/21/2020.

Historically, we've seen a performance hit on the X-Ray SDKs from generating IDs on every request (as we were generating it regardless of sampling).

We have since moved to a model of only generating an ID when the sampling decision is positive. Otherwise we stick in a valid default ID (just all zero'd out). Is this kind of construct supported on the current sampling/trace model?

[arminru]

Otherwise we stick in a valid default ID (just all zero'd out).

Please note that as per the W3C Trace Context specification all zeroes means invalid.

trace-id = 32HEXDIGLC ; 16 bytes array identifier. All zeroes forbidden
parent-id = 16HEXDIGLC ; 8 bytes array identifier. All zeroes forbidden
trace-id: All bytes as zero (00000000000000000000000000000000) is considered an invalid value.
parent-id: All bytes as zero (0000000000000000) is considered an invalid value.

-- https://www.w3.org/TR/trace-context/#version-format

[Oberon00]

We would need to inherit the parent context instead of generating a new one (do we do that already? What about the no-op case?). For traces that are unsampled from the root on, we do need to generate something though. I wonder if the W3C spec should be amended to allow e.g. a special trace id of all F to indicate "no ID available but please propagate traceflags and (if applicable) tracestate anyway.

[Oberon00]

I just noticed that we do not specify at all how span or trace IDs are to be generated when creating spans. I think this needs to be resolved before GA. It should be done after #932

[Oberon00]

Assigned p2, but could also qualify as p1

[Oberon00]

From the SIG meeting: If you have an unsampled child, propagate the parent span ID as my span ID.
What about root spans? Zero or new span ID?
Trace ID always needs to be generated (sampler input)

[Oberon00]

I think #998 addresses the most important part of this issue, but not the actual issue in the title, which would be a "default" trace ID. For that we would need to change the sampler API to not accept but optionally return a trace ID, or pass a function that lazily generates the trace ID or something. EDIT: That is, after #998 I think we can do the rest of this issue "after-ga", maybe together with #620.

[Oberon00]

@andrewhsu @open-telemetry/technical-committee I think while the issue in the title is after-ga, the part of the issue where the spec does not say at all what should happen with an unsampled span is required-for-ga (or should at least be allowed-for-ga, not sure what the guidelines are here).