Regarding the Multi-Modal http2 support ask from Traffic, can we vend two ports (http-service-mesh and http2-service-mesh) and then document the dev teams should just use the correct one depending on the protocol being used? For different paved roads (agentic streaming, etc) the default vended template code can use the appropriate port depending on the use case. That way we don’t need to make this another configuration in AIR that the user needs to do.

(BTW, seems like ALPN would be more for North-South traffic and isn’t really supported by Envoy for mTLS East-West traffic)
@ntantry @kdowney @ssh

9 replies

Kevin Downey  [10:48 AM]

Are we asking for a new port like 8091 ?

[10:52 AM]

So Mesh supports 3 protocols, HTTP, HTTP2 and GRPC.

I don’t think we want 3 ports, but maybe we can default to HTTP2 for 8090 and 8091 for grpc?

[10:52 AM]

HTTP1.1 still seems odd that it has to be hardcoded

Todd Ekenstam  [11:00 AM]

Assuming we want to just have two vended ports, here is a proposed task list of what we’d need to do to implement it:

IAIR — IKS AIR (Infrastructure Layer)
Goal: Expose both ports (http-service-mesh and http2-service-mesh) to services by default.
 Tasks:

• IAIR-XXXX: Update AIR service scaffolding to vend two mesh ports:
  • http-service-mesh → HTTP/1.1 (default) - 8090
  • http2-service-mesh → HTTP/2 (h2c) - 8091
• IAIR-XXXX: Add configuration flag to allow disabling one port if desired (protocolMode: http1 | http2 | dual). Default is dual.
• IAIR-XXXX: Ensure generated Kubernetes Services and DestinationRules set port.name correctly (http-, http2-).
• IAIR-XXXX: Add documentation and migration notes for teams moving from single-port to dual-port mode.

MESH — Traffic / Service Mesh Team
Goal: Enable routing, mesh policy, and envoy filter support for dual ports.
 Tasks:

• MESH-XXXX: Update default mesh configuration (EnvoyFilters, DestinationRules, VirtualServices) to support both HTTP/1.1 and HTTP/2 ports.
• MESH-XXXX: Add routing examples for mixed-mode (HTTP/1.1 + HTTP/2) services.
• MESH-XXXX: Verify compatibility with WebSocket over HTTP/1.1 and HTTP/2 streaming (h2c) scenarios.
• MESH-XXXX: Extend gateway configuration templates to route to either port explicitly.
• MESH-XXXX: Add integration tests to validate connection upgrade success, abnormal disconnects, and protocol stickiness.

Observability / Platform Metrics Team
Goal: Deliver visibility and autoscaling metrics for both protocols.
 Tasks:

• O11Y-XXXX: Add new metrics for active inbound HTTP/1.1 vs HTTP/2 connections.
• O11Y-XXXX: Emit golden signals per protocol: upgrade success, abnormal disconnects, latency, throughput.
• O11Y-XXXX: Update Splunk/Wavefront dashboards to visualize both connection types.

MSAASINT — Code Templates / Paved Road Team
Goal: Make the dual-port pattern invisible to developers (Day-0 ready).
 Tasks:

• MSAASINT-XXXX: Update Python Agentic Starter Kit (ASK/PSK) templates to connect to http2-service-mesh port by default for streaming use cases.
• MSAASINT-XXXX: Provide fallback config for HTTP/1.1 (http-service-mesh) to preserve backward compatibility.
• MSAASINT-XXXX: Add example routes in templates that demonstrate both ports (e.g., WebSocket over HTTP/1.1 + voice streaming over HTTP/2).
• MSAASINT-XXXX: Update Java Starter Kit (JSK) to emit Inbound HTTP(WebSocket) connection metrics for autoscaling.

IKS — AIR Autoscaling Team
Goal: Enable autoscaling that accounts for active connection counts (for http-service-mesh and http2-service-mesh ports), ensuring reliable scaling for long-lived streaming and WebSocket workloads.
Tasks:

• IKS-XXXX: Add support for new connection-based scaling metrics (traffic_active_websocket_connections, traffic_active_http2_streams) in the AIR autoscaling engine.
• IKS-XXXX: Integrate with the O11Y metrics pipeline to ingest and normalize connection count metrics from Prometheus/Wavefront, labeled by protocol (http1, http2).
• IKS-XXXX: Extend the autoscaling recommendation engine to include connection counts as an input when generating HPA recommendations.
• IKS-XXXX: Update the default HPA manifest template to include connection-based metrics

Caveat: Parts of this task list is GenAI-assisted; need to review/refine. Just offering this as a starting point for discussion and to correctly understand the scope of the ask.

[11:01 AM]

@vinit ^^ For your review.

[11:03 AM]

@kdowney I think gRPC runs over HTTP/2 so we wouldn’t need a third port, I don’t think.

Vinit Samel  [11:08 AM]

Thanks what’s the total cost for each domain in SPs?

Kevin Downey  [11:14 AM]

They have GRPC also as service object

Shankarram Shivram  [11:36 AM]

collating discussions - https://intuit-teams.slack.com/archives/C09D6FYAL1K/p1761326252829599 this is the thread with traffic

Shankarram Shivram  [10:18 AM]

@SumitMathur ^^

[10:22 AM]

Few questions and opinions we have

• We have concerns on leaky abstraction - asking users to switch between http1 and 2
• How can  this be addressed as an invisible concern for the customers - Could ALPN be used to solve this instead ?
• What are the implications of having http2 as default for the entire fleet vs having a selection choice (between http1 and 2 ?

Mahalingam M  [11:28 AM]

Thanks, @ssh.

We can have a meeting to discuss and close this. @Llavar Mindley, can you help setup a meeting to discuss this dependency on IKS AIR?

[11:32 AM]

• **We have concerns on leaky abstraction - asking users to switch between http1 and 2**  - This will be only for Agent Starter Kit services to start with (JSK in the future). For new Agents, we want them to start with HTTP2 by default. For existing agents moving to this model, we can support the migration transparently. Clarified this earlier, but we can discuss and close this.
• **What are the implications of having http2 as default for the entire fleet vs having a selection choice (between http1 and 2 ?** Based on the recommendation we have got from @jwebb3, HTTP2 will be more performance efficient in case of streaming use cases as compared to HTTP1 and the LLM vendors are also moving towards supporting HTTP2. So, for Agent Starter Kit services where the streaming use cases will be enabled, we can go with HTTP2 by default unless there are exceptions which we can handle on a case-to-case basis.

Thanks, @Avni Sharma. As discussed earlier, should be abstracted for users and handled by platform. @Sreejan Sur, @HariprasadK, Can you check and confirm this?

From a thread in tmp-agentcommunication-traffic-iks-pavedroad | Oct 8th, 2025 | View reply

Shankarram Shivram  [11:33 AM]

thanks maha -  Why only scope it to Agent starter kit services ? what are the implications of enabling it as default for all AIR assets ? (edited) 

Mahalingam M  [11:34 AM]

We are primarily targeting WebSocket over HTTP2 for Streaming scenarios. We have got a couple of other non-streaming use cases for WebSocket, but they are not our immediate priorities. For the latter, we need support on JSK.

Shankarram Shivram  [11:36 AM]

why not the existing ones (non websocket ) ones also for http2 ?

Nagaraja S Tantry  [11:39 AM]

@Maha kind of trying to decouple transport level which communicates over http2 always.. only the hop between proxy to app layer can be http2 or http1 depending on what app supports and I believe this should happen automatically (meaning it should downgrade to http1 if app supports only that)

Mahalingam M  [11:45 AM]

Thanks, @ntantry. I think we can discuss this in detail and close this.

@ssh, @ntantry, Apart from the questions above, if you have any other questions, please list them here. I will discuss this with the team before our meeting.

Todd Ekenstam  [11:54 AM]

@Maha I’m thinking instead of a config of http1 or http2, could AIR vend out two ports, HTTP/1.1 8090,  HTTP/2 8091? Then the vended application code can use whichever port is appropriate for it’s use case? (edited) 

Mahalingam M  [12:57 AM]

Thanks, Todd.

• @Venkata Krishna Murthy Vadrevu and @Sreejan Sur to evaluate this option.