Asynchronous multiplexing client requests in oneconnect session

Normally, as you observe, oneconnect uses a "serializing" model for message delivery. That is, it delivers a message from client to server, waits for the response, then sends the next request, and so forth. What you want is "pipelining", where client-side messages are delivered as they arrive without regard for responses. The challenge, however, is how to map the response segments back to the proper client. When the message requests are serialized, this is trivial to deduce because only one client-side segment is "inflight" at a time. When the messages are pipelined, however, unless all TCP segments are from the same client, there must be some keying information in the response that can be used to map the response segment to the originating client.

The LB::src_tag and LB::dst_tag are part of a system called TCP Message-Based Load-Balancing (mblb). If each TCP segment sent contains some key that can be used to match it back to the original client, and the response also contains either a.) the same key; or b.) a key that can be reverse mapped to the original source key, then that is a sensible way handle the condition you describe. This post:

• https://devcentral.f5.com/questions/use-of-lbsrc_tag-and-lbdst_tag

provides a sample. Basically, the code would extract whatever the identifying message key is from the client-side segment, and invoke LB::src_tag, passing it that key. This associates the client-side connection to that key. Then, when the server responds, you pass the same key to LB::dst_tag and the response will be routed to the original client-side connection. In order to use these, you must add the mblb profile to the Virtual Server. This can only be done with tmsh (that is, it cannot be done using the WebUI).

It sounds, from your post, that a key of this type is in fact available.

I believe that when mblb is used with the oneconnect profile, you will get the desired pipelining behavior; namely, BIG-IP will send multiple messages down the server-side connection without waiting for a response (by default, oneconnect will open new server-side connections if multiple client messages need simultaneous delivery), but I haven't tested recently to verify that my memory in this is correct.

Since TCP mblb is not well-documented, you might consider engaging F5 Professional Services to assist with this endeavor.