Support GRPC and HTTP2 without explicit port labeling

[rgregg]

In what area(s)?

/area networking

Describe the feature

Today to use GRPC or HTTP/2 for ingress into your service, you have to explicitly label the ports (see the GRPC sample: https://github.com/knative/docs/blob/master/docs/serving/samples/grpc-ping-go/sample.yaml)

However, the Runtime Contract states that the platform will perform automatic detection between HTTP/1.1, QUIC, and HTTP/2.

Unless overridden by setting the name field on the inbound port, the platform will perform automatic detection as described above.
Developers SHOULD prefer to use automatic content negotiation where available

[dgerd]

I have a proposal out to update this in the runtime contract to reflect our current behavior. Discussion on it can be seen here: https://github.com/knative/serving/pull/4035/files#r283535192

I suggest the update to the contract as we do not have line of sight to implementing this as it has strong dependencies on features in Envoy and Istio which AFAIK are not being worked on. Some background on how we landed this without automatic upgrade can be seen in this comment: #2539 (comment).

[steren]

Please do not close this issue by changing the runtime contract, this should be considered as a bug for Knative, even if fixing it will be hard due to Knative's use of Istio.

As a developer, I should not have to opt-into using HTTP2 to use HTTP2.

[rgregg]

Having the explicit choice for what protocol your app supports feels like a feature. This can help to catch errors in expectations that have performance implications in the differences between HTTP/1 and HTTP/2.

While the automatic detection could be a useful default, given the underlying dependencies in our stack cannot support those requirements. It's unclear Knative can even support this without significant work in Envoy and Istio.

Changing the runtime contract and aligning the expectations in the contract with what we can deliver feels like the right decision. We can re-evaluate that decision in the future if/when Envoy improves this experience.

[steren]

Please at least keep this open as a feature request.

[dgerd]

I commented this somewhere else, but pasting here and elaborating.

Our support today looks like:

(empty): HTTP/1.1 only
"h2c": HTTP/2 only
"http1": HTTP/1.1 only

This makes (empty) == "http1" in todays world.

I have concerns with making (empty) automatically upgrade to HTTP/2.0 in the future and leave the "http1" as the option with no upgrade. This breaks the equality between (empty) and "http1" which has the potential to 1) be breaking 2) be surprising to developers. I don't want to rule it out as our considerations and our understanding of developer expectations could change by the time we are able to implement this, but we should discuss at that time how automatic HTTP upgrading works and if it should be the default behavior.

I am fine keeping this issue open to track automatic HTTP/2.0 upgrades as a feature request.

[vagababov]

Concur with Dan. When we can, we should rather support `auto` and keep defaulting to http/1.1.

…

[tcnghia]

/assign tanzeeb