Complete the TraceIdRatio specification

[carlosalberto]

As part of the Sampling SIG (and as reported as part of #1819), TraceIdRatio is so far the preferred default sampler. However, related questions have arose, in order to complete such sampler specification:

1. Use sufficiently random trace IDs, specify how to evaluate the ratio test directly from TraceID bits
2. Propagate a new uniform random number in the range (0, 1] in the W3C tracestate to facilitate the ratio test
3. Specify that TraceIDs need not be "very random" but dictate the use of a standard hashing algorithm.

One detail to be aware of here is that some vendors may be providing their existing ids, so we have to make sure this works in all scenarios.

cc @jmacd @tedsuo @anuraaga @yurishkuro

[yurishkuro]

@carlosalberto wrote:
One detail to be aware of here is that some vendors may be providing their existing ids, so we have to make sure this works in all scenarios.

I agree with this - we cannot rely on trace-id to be completely random.

Of course there's always an option to support all 3 solutions via configuration, because some of them may be more palatable / suitable for different sites. For example, in my company option 2 would be very difficult to deploy, as many services are overly sensitive (i.e. can demonstrate numeric evidence of perf regression) to any extra payloads on the wire.

[jmacd]

Re: sensitivity to extra payload

This was why my original proposal in open-telemetry/oteps#168 used traceparent, because there we can get this support on-by-default for 3 bytes per context.

To me, the hashing option is the most difficult to specify and I would eliminate it. I can accept either a random TraceID or a tracestate entry, supporting both is within reason just a lot harder to specify.