How OneConnect Profile's max-size works

1. Preliminary Information

This setting controls the maximum number of idle server-side TCP connections that BIG-IP holds in the connection reuse pool split per tmm, i.e. if BIG-IP has 2 tmms setting max-size to 2 gives each tmm 1 idle connection. If HTTP requests reach the same TMM, then max-size of 1 and 2 will have the same effect in practice.

This is a quick walk through to show how OneConnect max-size works. For more general overview and description of each profile option individually please refer to one of the following resources:

• What is HTTP Part VII - OneConnect
• How OneConnect with Cookie Persistence works
• K7208: Overview of the OneConnect profile
• K2055: The BIG-IP system may not load balance traffic evenly when OneConnect is in use
• K85357500: Managing connection reuse using OneConnect source mask (12.x)

Think of this article as a quick lab test so we can quickly understand what oneconnect max-size is along with corresponding tmsh show command output

2. Lab Scenario

My BIG-IP (VE) box has 2 tmms:

I've set max-size to 2 and left everything else with default settings (setting to 1 would have the same effect)::

This roughly makes max-size = 1 per tmm.

We can now play with 'show' commands and understand a bit more about OneConnect using fewer requests.

This is the scenario:

I added the following iRule to the virtual server to make it simple and confirm whether connection has been re-used or not:

3. Lab test results

• BIG-IP adds eligible connections to OneConnect reuse pool
• max-size value set is split per tmm
• If max-size has been reached in a given tmm, new eligible connection is not added to connection reuse pool
• In such case, such connection is closed (FIN/ACK) when we receive another request that could potentially reuse it and BIG-IP creates a new one

Note: In this lab test I am using Current Idle output from tmsh show ltm profile one-connect  as a reference to understand connection reuse pool because it is a controlled environment and this is the only kind of traffic BIG-IP is receiving. However, Current Idle actually shows current number of any idle server-side connection, even if it is not in connection reuse pool, i.e. either not eligible because of source-mask configuration or because it hasn't been claimed to be reused yet for the first time.

4. Explanation of show command output

Current Idle: number of current idle server-side connections regardless if it is eligible or not to be reused

Maximum: number of maximum concurrent connections a single tmm has ever handled

Total Reuses: Goes up when any idle connection is reused

New: Goes up when BIG-IP establishes any new connection server-side

5. Lab test details

I sent first HTTP requests via curl from client (10.199.3.135):

And it goes to Server1:

At this moment, server side connection is immediately added to connection reuse pool (Current Idle):

I then send 2nd request and it goes to Server2:

Because max-size is set to 1 then there is no room for another eligible idle connection and old connection is closed to give room to a new connection.

This explains why New counters increases to 2 (since this is the 2nd new connection this profile handled since the counter started) and Current Idle remains at 1 (because max-size only allows 1 idle connection server-side, remember?):

3rd request comes in and round-robin method determines it should go to Server1 but as there is an idle connection in connection reuse pool this time BIG-IP reuses it (notice port 38742 is the same port):

And fair enough Total Reuses go up:

4th request to Server2 also creates a new connection that is also closed because connection reuse pool still contains Server1 connection entry:

New entry increases again as it is a new server-side connection but Current Idle (connection reuse pool) does not:

I have now set max-size to 4 and that gives 2 max entires per tmm and now I see connection being reused once for both pool members because BIG-IP now can leave up to 2 idle connections open:

The 'tmsh show ltm profile oneconnect myoneconnect' output reflects that:

Because the same tmm instance (tmm0) handles all the requests, a max-size of 4 gives tmm0 2 spots for idle connections which also explains why a 2nd new connection is never added to Connection Reuse pool and Current Idle didn't go above 2.