What is HTTP Part VII - OneConnect

In the last article in this What is HTTP? series we finished covering the settings in the HTTP profile itself. This week, we begin the transition to technologies that support, enhance, optimize, secure, and (insert your descriptive qualifier here…) the HTTP traffic flowing through the BIG-IP, starting with OneConnect.

What is OneConnect?

What comes to mind when you hear the phrase “Reduce Reuse Recycle”? Does a little green pseudo-triangle with arrows flash before your eyes, or do you think if they really cared about the reduction, the phrase would be “re[duce|use|cycle]”? But I digress.

OneConnect reduces the number of server-side connections between the BIG-IP and application servers by reusing the existing server-side connections. So whereas you might be serving thousands of connections on the client-side, there will be a reduced number of server-side connections to offload the overhead of tcp connection setup and teardown.

You can see in the image above that before HTTP/1.1, single requests per connection on client and server sides resulted in inefficiencies. With HTTP/1.1, you can multiplex requests on single connections client-side, and as shown below, can multiplex multiple client-side connections onto single server-side connections. This is the power OneConnect offers.

Both clients multiple requests in a single tcp connection for each client are pooled together on a single tcp connection between the BIG-IP and the server. There’s even hope for HTTP/1.0 clients via the OneConnect Transformations I mentioned in part five of this series.

In this case, the four individual connections on the client-side of the BIG-IP are transformed into a single connection on the server-side thanks to OneConnect.

The OneConnect Profile

Let’s start with a screen shot of the fields available in the OneConnect profile. As this is the default parent, you don’t have the option to name it and set the parent, but when creating a custom profile, those settings would be available for configuration as well in the General Properties.

Source Prefix Length

Also known as the Source Mask field in earlier versions, this is where you specify the mask length for connection reuse. It’s important to understand that this is the contextual source IP of the server-side connection. This means that if you are using a SNAT address, it is applied before the mask length is evaluated for OneConnect reuse eligibility. The masking behavior details by version are maintained on AskF5 in knowledge base articles K5911 (10.x - 11.x) and K85357500 (12.x.) In my current lab version of 12.1.2, the prefix length can be set to IPv4 or IPv6 mask lengths, and are supplied in CIDR notation instead of traditional netmasks. There’s no rocket science to the mask itself, a mask-length of 0 (default) is most efficient as OneConnect will look for any open idle tcp connection on the destination server. A length of /32 for IPv4 or /128 for IPv6 is a host match, so only an open connection between the source host IP (or SNAT) and the destination server would be eligible for reuse.

Maximum Size

This setting controls the maximum number of idle server-side tcp connections that BIG-IP holds in the connection reuse pool. This value is divided by the number of TMMs on BIG-IP, so for the default of 10,000 on a system with 10 TMMs, the maximum number of idle connections per TMM would be 1,000. This can be tested with an artificially low maximum-size of two, which means one a two TMM system only one idle connection is available per TMM in the connection reuse pool. Let's use this iRule to make it simple to confirm whether connection has been reused or not:

when HTTP_REQUEST_RELEASE {
 log local0. "BIG-IP: [IP::local_addr]:[TCP::local_port] sent [HTTP::method] to [IP::server_addr]:[serverside {TCP::remote_port}]"
}

If we have two servers and send two requests to them, each request goes to each server respectively (everything except max size here is default with round-robin LB method.)

Rule /Common/check_oneconnect : BIG-IP: 172.16.199.234:38648 sent GET to 172.16.199.31:80
Rule /Common/check_oneconnect : BIG-IP: 172.16.199.234:38650 sent GET to 172.16.199.32:80

The server2 connection (from second request) is not added to the connection reuse pool because max size is set to 2 (1 per TMM) and server1 is already there. The third request goes to server1 and reuses the connection from the first request (src port 38648):

Rule /Common/check_oneconnect : BIG-IP: 172.16.199.234:38648 sent GET to 172.16.199.31:80

The fourth request goes to server2 and because there are no idle connections open to server2 then a new connection is created:

Rule /Common/check_oneconnect : BIG-IP: 172.16.199.234:38646 sent GET to 172.16.199.32:80

The fifth request again goes to server1 still reusing the idle server1 connection:

Rule /Common/check_oneconnect : BIG-IP: 172.16.199.234:38648 sent GET to 172.16.199.31:80

A sixth request to server2 also creates a new connection because server1 is still occupying the only spot available in the connection reuse pool:

Rule /Common/check_oneconnect : BIG-IP: 172.16.199.234:38658 sent GET to 172.16.199.32:80

Maximum Age

This is the maximum number of seconds that a connection stays in the connection reuse pool before the BIG-IP marks a connection ineligible  for reuse. Two key points on the max age:

  • It is triggered after the first time the connection is reused, not when the connection is used for the initial request. It is only after the first reuse is completed and the connection is idle that the max age countdown begins.
  • The max-age setting does not close connections when expired, it marks connections ineligible for future reuse. They are then closed in one of two ways. The first way is the BIG-IP will close an ineligible idle connection when a new request comes in. The second way is to wait for the server’s HTTP keep alive to time out. Both sides of the connection have the ability to close down the connection.
Let’s take a look at the max age behavior by setting it artificially low on the BIG-IP to 5 seconds, and setting the test apache server to 60 seconds to prevent apache from closing the connection first. If we send one request (frame 10) only the connection is closed 60 seconds later (frame 46) honoring the keep alive we set on apache:
 
 
The max age did not kick in here as the connection was not reused. However, let’s make another initial request (frame 10.)
 
 
This time we make a second request (frame 51) 20 seconds later but before the 60 second timeout. Notice the connection has been reused
 
 
Now that the max age setting has kicked in, we wait another 20 seconds (well after the 5 second expiration we set) and BIG-IP closes the previous connection (frame 77) and opens a new one (frame 92.) One the new connection is established the client-side request is sent to the server (frame 96.) You can also see that after another minute of idleness, the apache server keep alive timeout has expired as well, and it closes the connection (frame 130.)
 
 
If we had opened a new connection within 5 seconds after frame 115, then the connection would have been reused, and then max-age would kick in again immediately after the connection was idle again.

Maximum Reuse

This setting controls the maximum number (default: 1,000) of times a particular server connection can be reused before it is closed. So for example, if you set the maximum reuse to two connections, a server-side tcp connection (172.16.199.234:63826 <-> 172.16.199.31:80) would be used for three requests (one initial in frame 10 and two reuses in frames 49 and 90,) and then BIG-IP, unlike with max age in marking a connection ineligible, will immediately close the connection (frame 119.)

Idle Timeout Override

When enabled (disabled by default,) this setting overrides any timeout set by protocol profiles such as tcp which has a default timeout of 300 seconds. So with the BIG-IP tcp idle timeout at 300 seconds and apache (from earlier) set to 60 seconds on the keep alive, the idle connection will be closed by the server. If we set the keep alive to 301 seconds, BIG-IP would reset the connection. For the sake of testing the idle timeout override, however, let’s enable the idle timeout override in the OneConnect profile by setting it at 30 seconds.

You can see in the capture above that after the request is completed (frame 33) and the connection is now idle, it is reset after 30 seconds (frame 44,) occurring before the server timeout and the BIG-IP tcp timeout. You can also set the idle-timeout-override to infinite, which will ignore the other BIG-IP protocol timers but not overcome the settings of the server keep alives.

Limit Type

 This setting controls how connection limits are managed in conjunction with OneConnect.

  • None (default) - OneConnect is not involved with the connection limits.
  • Idle - Specifies that idle connections will be dropped as the tcp connection limit is reached. For short intervals, during the overlap of the idle connection being dropped and the new connection being establish, the tcp connection limit may be exceeded.
  • Strict - Specifies that the tcp connection limit is honored without exception. This means that idle connections will prevent new tcp connections from being made until they expire, even if they could otherwise be reused. This is not a recommended configuration, but might prove useful in exceptional cases with very short expiration timeouts.

Understanding OneConnect Behaviors

OneConnect does not override load balancing behavior. If there are two pool members (s1 and s2) and we use the round-robin load balancing method with OneConnect applied, the behavior is as follows:

  1. First request goes to s1
  2. Second request goes to s2
  3. Third request goes to s1 and reuses idle connection
  4. Fourth request goes to s2 and reuses idle connection
Applying a OneConnect profile to a virtual server without a layer seven transactional (read: clearly defined requests and responses) protocol like HTTP is generally considered a misconfiguration, and you may see odd behavior when doing so. There may be exceptions, but this configuration should be considered carefully and tested thoroughly before deploying to a production environment.
 
Without OneConnect on a virtual server with HTTP, you will find that persistence data does not appear to be honored. This is because by default, the BIG-IP system performs load balancing for each tcp connection, not each HTTP request, so further requests on the same client-side connection will follow suit from the original decision. By applying OneConnect to the virtual, you effectively detach the server-side from the client-side connection after each request, forcing a new load balancing decision and using persistence information if it available.
 

Resources

Thanks to Rodrigo Albuquerque for the fantastic test source material!

Published Nov 06, 2017
Version 1.0

Was this article helpful?

5 Comments

  • Hi,

     

    Nice recap! I think there is one small error here:

     

    The fourth request goes to server2 and because there are no idle connections open to server2 then a new connection is created:

     

    Rule /Common/check_oneconnect : BIG-IP: 172.16.199.234:38648 sent GET to 172.16.199.31:80

     

    [TCP::local_port] should be different [IP::server_addr] should end with .32

     

    I am still not sure when TCP profile Idle Timeout kicks in. Only scenario I can imagine is when:

     

    • Server Keep Alive timeout is grater that value set for TCP Idle Timeout
    • Single request is send from client, so TCP connection to server is created
    • No more requests are sent over this connection for period longer than TCP Idle Timeout

    Is above correct?

     

    I am as well curious why after Max Age is over connection is not closed by BIG-IP? Seems that waiting for server to close is preferred but exactly why it's preferred?

     

    What will happen if server will send anything over connection marked as illegible for reuse? Packet will be accepted, dropped? Will it influence connection state - so it will be marked back as eligible for reuse?

     

    Why there is such difference between handling connections that exceeded Max Age and Maximum Reuse? If it's preferred to have server close connection why for Maximum Reuse same strategy as for Max Age is not used?

     

    Idle Timeout Override - similar question as for TCP Idle Timeout - when this timeout will be used? Only when connection was never reused?

     

    You can also set the idle-timeout-override to infinite, which will ignore the other BIG-IP protocol timers but not overcome the settings of the server keep alives.

     

    It's obvious that server timeouts can not be overridden, but which BIG-IP timeouts are in this case? TCP Idle Timeout? I do not expect that this setting overrides Max Age - am I right?

     

    And last one, there are two settings related to reuse. I assume that the first one that hits threshold wins, so if Max Age never was reached but Maximum Reuse was connection will be closed, and vice versa?

     

    Piotr

     

  • error fixed, thank you.

     

    answers, in order of your questions (I think):

     

    1. tcp idle timeout: yes, that sounds about right
    2. max age: putting onus on server give BIG-IP less to do on something inconsequential (my guess, no insight from the developer)
    3. marked ineligible: ineligible status is linked to attaching client connections to server connections, not servers using active connections
    4. max reuse is using counters, not timers, so I'm not sure how server could be expected to participate
    5. idle-timeout override is to give control to oneconnect over other protocol timers, so if server keepalive timeout is 60 seconds and default tcp profile timeout is 5 minutes, and you set oneconnect idle-timeout override to 30 seconds, the connect will be reset by BIG-IP after 30 idle seconds
    6. Max age timer is how long it's allowed to sit in the re-use queue, not exactly the idle-time of the connection itself, it's a different timer.
    7. All the timers are independent such that they will act on the information they have when thresholds are crossed, so if max age is violated, it acts regardless of max reuse status (and vice versa)
  • Hi,

     

    Thanks for answers.

     

    Considering point 4. Sure it's counter, but after counter counts to set value it could marke connection as illegible for reuse - same as for Max Age, then use identical algorithm - if next client request is first then it is closed by BIG-IP if server keep alive is first then server closes connection.

     

    I am a bit unsure about your logic here, for both settings server is not aware what is going on on BIG-IP side so why to use separate algorithms for Max Age and Max Reuse?

     

    Piotr

     

  • good explanation. it is very important to understand that OneConnect does not override Load Balancing. The 2 concepts are compatibles.

     

  • Good explanation It is very important to understand that OneConnect does not override Load Balancing. The 2 concepts are compatible. How well Oneconnect works with Fastest (Application) LB ?