Add protocol support for 128-bit (16-byte) trace IDs

[springheeledjak]

OpenZipkin has added support for 128-bit trace IDs, which have a number of advantages over 64-bit ones (also enumerated in the linked issue). It would be useful to support 128-bit trace IDs in TChannel, as it would enable more seamless integration with, among others, AWS' X-Amzn-Trace-Id header and GCE's X-Cloud-Trace-Context / Stackdriver Trace. Span IDs remain 64-bit in both Zipkin and Stackdriver, so that field should stay the same. (128-bit span IDs don't make much sense anyway.)

Due to the fixed nature of TChannel headers, this may end up being something of a pain, possibly involving a new protocol version to allow for negotiation during the init phase.

[kriskowal]

@springheeledjak It may be that the best way to accomplish this is with arg2 request headers and to simply leave the TChannel trace as null. It’s very unlikely that my group or my company's opentracing group is going to invest in a protocol revision for this feature.

However, if there is broad community interest in building and supporting a protocol rev, let the relevant parties chime in here.

[springheeledjak]

@kriskowal Hm, didn't think of that; using arg2 headers sounds like a reasonable approach. I suppose a pair of init req/res headers could be used to signal intent to use arg2 headers and acceptance, which would serve as the negotiation/downgrading mechanism.

[kriskowal]

Oh, by way of background, since we framed TChannel protocol some time ago, we have learned a few things that are relevant:

• In practice, we have never needed to rewrite a frame's tracing information in-place. It's sufficient to read and report timing in the forwarding layer, and we haven't even done that in practice.
• There is hypothetical utility in having a unique identifier in the tracing fields for use in Claim messages, but we never implemented Claim either.
• While it's interesting in theory for arg1 and arg2 to have a free form depending on the "argument scheme", in practice we really only need arg3 to be encoding-dependent. Having free-form arg2 in raw encoding turns out to be useless, so we've tended to use the same headers encoding as Thrift, particularly in YARPC. Having arg2 formatted in JSON for the JSON encoding is an annoying exception to the rule. If we went forward in time and reved TChannel protocol, we probably would subsume arg1 and arg2 in the CallReq frame, leaving only arg3 to be eligible for fragmentation and streaming.