Little endian vs Big endian

[bogdandrutu]

Some people raised the issue related to the endianess that we use for the trace-options. We need to agree on one of the endianess and use that to encode the trace-options and any future fields.

The current proposal is to use little-endian because it is more natural for all CPU architectures (probably >90% CPUs in used are little-endian).

The suggested proposal was to use big-endian because it is more human-readable, also default in Java and the network-order.

Please vote here for one or the other.

[bogdandrutu]

Another proposal was to reduce this to 1B and avoid discussion about endianess if we need less than 8 bits (options). This may be a reasonable thing to do for v0.

[yurishkuro]

+1 to use a single byte in v0.

I guess a question if someone argues for 4-bytes: if the standard does not define any meaning for the rest of the bits, then what are the semantics of encoding implementation-specific data there? Should the tracers simply pass through the non-standard data? Maybe we just need another "custom" field for that, with some arbitrary but fixed length that is treated as opaque byte array.

[cce]

I have the same question — if you receive some trace-options bits set, how do you know if it was the same tracer implementation as your own that set them? This assumes that most orgs will run the same tracer implementation across all their services, which may usually be true. But any HTTP requests across services or organizations running different tracers risk unintended consequences if they use the other bits and the remote tracer implementation "trusts" them blindly as having semantic meaning coming from their own implementation.

For example the spec says "Controls tracing options such as sampling, trace level etc," so if you use 0x2 for debug-level tracing and 0x4 for production-level tracing and I use the opposite, what other means of provenance would you recommend vendors use to make sure they don't misinterpret options that are received? (A separate header or some identifier embedded in the trace ID?)

I think the answer may just be "don't trust trace-options from HTTP calls over the public Internet" which is a fine answer... but should probably be called out in the spec.

[bhs]

I like 1-byte as stated earlier.

If we're doing 4-byte, I am confused why we care about processor endian-ness given that this is a non-binary encoding. Surely it doesn't matter at all from a real-world performance standpoint, esp given that all of this is only relevant in the context of an HTTP request where there are syscalls, significant I/O, etc, etc. Let's optimize for comprehensibility (yet without doing anything silly).

[codefromthecrypt]

considering the ambiguity around how flags can be used (especially if the spec later needs to gobble more bits of them), I like 1 byte.

Not only does this obviate endianness (since there's no bit endianness), but also it takes out some distraction: I'm not sure how much help the extra bytes will be in practice, as there's no way to identify a vendor anyway.

[devinsba]

I think that since this is already a string the choice of endianness should be best chosen for that representation (human readable), since there will already have to be a decode step to convert to byte(s)

[codefromthecrypt]

PS there's something that is easy to lose in translation as ex in chinese endian is higher/lower

To consider impact of not defining endianness, an example is good. As soon as there's more than one byte of flags, it matters. For example 1025 is encoded either 0401 or 0104 depending on endian/higher|lowerness

more here http://www.yolinux.com/TUTORIALS/Endian-Byte-Order.html

[bogdandrutu]

I think the current format does not need an endianness definition because it uses byte-arrays for ids and 1B for options which does not have endianness.

If anyone wants to have the ids as numbers probably big-endian makes more sense because they are closer to byte-arrays hex representation.

[codefromthecrypt]

The endian-ness is really only a matter of how backends choose bit count less than 128. ex there are systems that will choose less than 128 when storing. Being consistent about endian matters in this case.. it doesnt matter for numeric, rather which side of the array you toss.

…

On 14 Jul 2017 21:38, "Bogdan Drutu" ***@***.***> wrote: I think the current format does not need an endianness definition because it uses byte-arrays for ids and 1B for options which does not have endianness. If anyone wants to have the ids as numbers probably big-endian makes more sense because they are closer to byte-arrays hex representation. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD613EVIunax5SAVITZZTBAaeXOWDG3ks5sN29vgaJpZM4M5IW8> .

[bogdandrutu]

Correct, but I think we can move this decision to the service backend implementation details.