Define behavior when library do not understand the version number

[SergeyKanzhelev]

The behavior may differ between not being able to parse header and unknown version number. Spec should make some considerations for the versions revision in future.

[SergeyKanzhelev]

I was thinking about this one. I feel we can make a good use of tracestate here. So if one sees unknown version prefix - behavior may be the following:

• Pass-thru the traceparent
• Start a new trace. Let's say it's 00. Place it into tracestate like:

Incoming:

traceparent: 02-abcdefg
tracestate: vendor1=opaqueValue1

Outgoing (from the system that only knows about 00):

traceparent: 02-abcdefg                                        //unchanged
tracestate: v00=00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01, vendor2=opaqueValue2, vendor1=opaqueValue1

This will require:

1. Reserver vXX keys in tracestate
2. Recommendation: define the size limit as a sum of tracestate and traceparent. So size-critical systems will be able to deal with higher version of a header if it will be longer. It will just eat up some tracestate space
3. Parsing will be a bit more involved for the cases with the unknown version of traceparent. Now you'd need to look up v00 header in case it was already started before.

[SergeyKanzhelev]

@yurishkuro since you seems to be around - do you have an opinion here? Does this approach looks reasonable for you?

[yurishkuro]

Sorry, I don't have an opinion about this. I'd like to see first the whole thing working even with a single version and understand all the edge cases before prescribing behavior for mismatched versions.

On the first glance, adding v00= seems unnecessary, since the next hop will received v0 traceparent and its own state may or may not be found in the tracestate.

I think downgrading the version is reasonable and should be allowed, while upgrading the version should not be allowed. Aside from that I don't know if we need any other prescriptions.

[SergeyKanzhelev]

I think downgrading the version is reasonable and should be allowed, while upgrading the version should not be allowed.

Can you elaborate on this? My thinking was quite opposite. If downgrading will be the default behavior than it will be very hard to move to the next version. Any component that is stubborn to upgrade will break features of the next version.

[yurishkuro]

When a node receives N+1 version but only understands N, it has no choice but to start a new trace. So if you have A->B->C where A and C only know N, but B upgrades to N+1, then it will force a broken trace in C even if it didn't have to. If both A and B understand N+1, then the trace will still be broken at C, but nothing could be done.

So upgrading potentially forces a broken trace when it could've stayed unbroken.

[SergeyKanzhelev]

So if you have A->B->C where A and C only know N, but B upgrades to N+1, then it will force a broken trace in C even if it didn't have to.

So while upgrading from lower version - this lower version should be moved to tracestate. It will indicate that upgrade has happened.

If both A and B understand N+1, then the trace will still be broken at C, but nothing could be done.

In this case if C will simply pass thru traceparent - it will became invisible for the A->B correlation. But B will know something happened because there will be new tracestate update with v00 key.

It is a great point that if component wants to upgrade - it needs to preserve original one in tracestate!

[nicmunroe]

I'm a little confused with the use case here - are we talking about a case with A->B call, and both A and B are using the same tracer/vendor, but A is sending a version format that B doesn't understand? Or is it different tracers/vendors between A and B?

Maybe the answer is the same in either case - B has to start a new trace for its trace graph unless it finds something in tracestate that it understands, yes/no?

[SergeyKanzhelev]

This issue is about how we will migrate to the new format when time will come. The idea here is independently from vendor - it is important to keep newer version flowing in traceparent to promote progress. And you need to look for version you understand in tracestate collection under well-known name.

All this assume that tracestate does not require versioning

[nicmunroe]

traceparent is just telling you what your immediate predecessor did, not what the entire call-chain is doing, yes/no? All the "real" state for a given tracer/vendor is going to be in tracestate, and since tracestate values are opaque and tracers/vendors can version their state completely independently of the the incoming call's traceparent version, the traceparent version doesn't make or break what the receiving service is doing. I think?

I feel like I'm missing something here. Could be entirely on me.

[codefromthecrypt]

I am also a bit confused but can hazard a guess. are we simply saying trace state owners "may" consider the version number in the transparent header? even if this were the case we are supposed to not depend on anything in traceparent.. even if it were a choice to, that would be trace state format specific right? can we come up with motivation where this matters and how any choice here would affect something albeit docs or impl?

[codefromthecrypt]

I think maybe 2 issues.. how we handle version updates in traceparent and if state definitions are traceparent version specific. personally I think the tracestate cannot be traceparent version specific. maybe we discuss this next week?

[SergeyKanzhelev]

yes. Let's discuss it on workshop.

This proposal is just clearing up the way for spec evolution. Since we including the version prefix in traceparent we need to explain how to deal with the unknown version. Throwing everything away as "incorrect format" and restarting trace is not ideal for future trace evolution. Thus this proposal.