Additional Protocol Support

[jkowall]

Today's OSS tracing systems are focused on http, the typical enterprise has a lot of other protocols which are critical to the application. Some examples include:

• 1. JMS
  Data can be embedded in message properties without harm, and this allows correlation and identification of the presence of a messaging system. The data can be tagged going in and measured for message put. Similarly, the receiving end can measure the time in the queue and the time it takes to process said message.
• 2. Native MQ
  This is more difficult to handle since native MQ protocols do not have specific areas where message data can be inserted without the fear of breaking the downstream legacy code. There are several tricks here which can help avoid the problem, and there are published recommendations from IBM, Tibco, and others. The problem is that the downstream applications typically ignore the recommendations.
• 3. AMQP
  Similar to JMS, supporting AMQP is possible due to having extensible message formats. This still must be done by the library or programmer to inject the right data into the message.
• 4. DB Calls (JDBC / ADO.NET / other DB access types)
  Although this is not something I've seen tracing tools do today, it could be of use to have similar data going to the database. This is something that Oracle has done internally, for example, the database can automatically record a transaction id with the record for trackability (https://docs.oracle.com/cd/B19306_01/java.102/b14355/endtoend.htm#BEICGHJH). It would depend on the driver and database but could be of use.
• 5. RMI or other RPC
  In Java, these calls would typically be via CORBA or via raw calls to a downstream system. For things like CORBA, there are fields which are available to do this type of thing. Similarly, on Hadoop RPC (https://wiki.apache.org/hadoop/HadoopRpc) this would be possible as well. Some of these would require adding data to a message on one end, and possibly removing it on the remote end to avoid breakage.
• 6. Protobuf and other binary protocols
  These are potentially interesting technologies we could embed into, but once again it depends if we can remove the data before it's processed downstream, or find a way to embed data into the payload without causing issues. This is currently a challenge for APM tools.

[wu-sheng]

We can discuss them when we have settled the HTTP.

[objectiser]

Although we may want to deal with HTTP first, I think it would be good to structure the report on the basis of defining the "core" concepts first (i.e. three header types), and then protocol bindings separately (initially just HTTP) but would then be easy to extend later. This is the way other w3c specs seem to work.

[SergeyKanzhelev]

@objectiser I started this overview https://github.com/w3c/distributed-tracing/blob/master/abstract/overview.md Is it what you suggesting?

[objectiser]

@SergeyKanzhelev No, I was meaning that the report structure should discuss the three types of information (headers) initial independently of HTTP - so just describe their purpose and the structure of the value. Then in separate section describe the bindings - with initially just one section for the HTTP binding, where actual header names and encoding can be described. So any protocol specific details are dealt with separately.

[codefromthecrypt]

I do see value in discussing concepts separately, but as there's a lot about encoding here, I don't expect a clear separation to survive towards open-ended protocols, especially knowing what we know about binary encoding. I'd recommend we refactor later as it is more honest with the state of affairs we can describe.

Many efforts cite open-endedness, but without mechanics to achieve that. Let's not get bogged down or hint that solving http solves anything else in the same way. If we must break navigation by splitting into parts, which people will need to scroll up and down to get to, let's make it count.. like have that happen when there are multiple encodings defined.

my 2p

[codefromthecrypt]

Adds an associated discussion from Brave, as JMS (a java messaging api) has some constraints that affect propagation portability openzipkin/brave#584

[SergeyKanzhelev]

Some finding after writing specs for binary, AMQP and MQTT protocols. Two big ones:

Charset of tracestate value

HTTP-imposed limitation on character set of the opaque value of tracestate value doesn't may not be an issue for other protocols, which generally support UTF-8 charset. This potentially may lead to various issues like one may assume UTF-8 charset for messaging protocol and will assume something like urlencoding will be applied to non-ASCII characters. However specification operates with opaque values and does not assume any encoding. So value may be simply dropped by implementation.

One of the way to solve it is in fact suggest some encoding mechanism specifically for HTTP protocol. This will, however, complicate implementations and is hard to test in existing test harness (it only supports binary now).

Parsing of tracestate

Binary protocol and AMQP benefits from having a list of tracestate values, not simply treating it as a string. However, this format adds a requirement for every implementation to have a parsing logic for the tracestate implemented. Even if implementation simply wants to forward it from HTTP to GRPC or AMQP.

[nrktkt]

Over on the JSON-RPC mailing list we've been talking about creating a trace context for JSON-RPC.
Is there a way we can get a repo under the w3c org (w3c/trace-context-json-rpc) to start drafting?
Please let me know if there's another, better place to discuss.

[SergeyKanzhelev]

@kag0 if you want to host it someplace else - you can follow this example: #11

Having spec under w3c org may create unnecessary overhead for you, but if needed I believe it can be done. @caribouW3 any objections?

[nrktkt]

@SergeyKanzhelev we'd prefer the formality of having it as a w3c spec, but open to alternate directions as we progress.

[SergeyKanzhelev]

@kag0 added to the agenda of the next meeting: https://docs.google.com/document/d/12AAIbnkt_AH1YjZwUwxirX_7WA7aWOSXpDweCgfqIiQ/edit#heading=h.g9nd8akmp2p2 Next meeting on calendar is Dec 1st.

My understanding is that nothing should prevent us from having this repository. I believe contributors/editors for the spec must be in w3c org which may be a blocker for some people to participate (just something to consider).

[nrktkt]

Yes that might be a bit of a blocker. @AArnott and I are the two people working on it, and neither of us are in w3c.
So one or both of us would need to join w3c if we wanted to author content for the spec? ie. we can't open PRs and have someone inside the org merge them?