Discussion: supporting alternative L7 protocols based on UDP & TCP

[beriberikix]

I've recently discovered SMI and have enjoyed digging into the specs. I'm hoping to kickoff a discussion on how we should be thinking about defining new L7 protocols, to make sure the right abstractions exists in v1.

As the reader may already know, there are many IP-based protocols in the world beyond HTTP. Here's just a few of the ones I've investigated for use with a service mesh, as well as their category and protocol:

• IoT - CoAP:UDP, MQTT:TCP
• Gaming - GameNetworkingSockets: UDP, netcode.io:UDP
• Telephony: WebRTC:UDP
• IP Suite: DNS:UDP, NTP:UDP, TFTP:UDP

The specs are currently focusing on HTTP but note that the goal is to support more protocols in the future. For example, Traffic Specs states, "There are many different protocols that users would like to have be part of a mesh. Right now, this is primarily HTTP, but it is possible to imagine a world where service meshes are aware of other protocols. Each resource in this specification is meant to match 1:1 with a specific protocol. This allows users to define the traffic in a protocol specific fashion."

In addition to the traffic spec, I believe there's a few other points to allow other protocols:

1. Traffic Access Control allows a kind that can be different depending on what traffic protocol a target is serving
2. Traffic Splitting can select the filter to use with spec.matches
3. Traffic Metrics doesn't have any protocol-specific bits, afaict

Is that a correct summary? If so, I'd love to begin a discussion about what else might be needed or missing to support other protocols in the future!

Note: I started a related discussion at envoyproxy/envoy#10140

[grampelberg]

@beriberikix HTTPRouteGroup and TCPRoute are exactly for this purpose. From a spec perspective, feel free to suggest a spec that would cover what problem you're looking to solve! The next step would be introducing that support into a service mesh implementation.

[beriberikix]

Great to hear! So how would we go about defining a spec for something like CoAP/UDP? Would it be a new spec or some sort of extension to the traffic spec? Is there a mechanism for optional protocols, similar to how CloudEvents does it?

[grampelberg]

So how would we go about defining a spec for something like CoAP/UDP?

Get a proposal up!

Would it be a new spec or some sort of extension to the traffic spec?

It would be a separate CRD, following the pattern of a resource per protocol that is there so far. I don't see a reason that we need a separate doc for each protocol today though.

Is there a mechanism for optional protocols, similar to how CloudEvents does it?

All of SMI is optional today, so I think that works? I don't understand how CloudEvents is doing it.

[beriberikix]

I'm still learning the spec but I believe there's a vendor/protocol neutral core spec that defines MUST have fields, minimum format (like MUST support at least JSON) and is intended to be inherited by all event types. Therefore there's dedicated HTTP and JSON specs.

Scalable and DRY - but perhaps premature for SMI?

[grampelberg]

Our plan is to have a compatibility matrix that shows what implementation supports what. We've just not built the tooling out to generate that quite yet =)