Under normal circumstances (Allow Dynamic Record Sizinguntickedon Client SSL profile), as the size of TCP Congestion Window grows to a certain size, BIG-IP typically sends TLS responses to client using a mostly fixed TLS record size.
However, for long-lived connections, e.g. download of large files, TLS performance can massively increase by using a more dynamic approach with larger TLS records and BIG-IP supports that.
When Allow Dynamic Record Sizing is enabled, BIG-IP dynamically adjusts optimal TLS record layer size when forwarding traffic to client based on the state of TCP connection, i.e. TCP congestion window.
How typical TLS connection behaves without Dynamic Record Sizing
I captured a download of 70 MB from BIG-IP's HTTPS virtual server (10.199.3.101) to client (10.199.3.135) and here's the stats output of client-ssl profile with allow-dynamic-record-sizing disabled:
Notice we had a couple of small TLS records and then pretty much everything else was between 2-3K range.
Looking at my packet capture and filtering TLS records per length/size, this is our breakdown we get:
When TCP congestion window stabilises and BIG-IP starts sending data (70 MB dummy file) to client, TLS record size settles on 2920 bytes from frame #169 onwards until the end of the connection:
Note: I created a new Wireshark column so we don't need to dig deeper into headers to visualise TLS record size.
Before we compare above behaviour with the one we get when Dynamic Record Sizing is enabled, let's first quickly understand how Dynamic Record Sizing works.
How Dynamic Record Sizing works
The algorithm behaves in the following manner:
When tcp congestion window is low (e.g. beginning of connection), send one TLS record per TCP packet
When tcp congestion window is large AND we're transferring a large stream, then TLS record can be increased up to 16 KB to reduce framing and CPU overhead on client and server
How TLS connection behaves with Dynamic Record Sizing enabled
If we compare the behaviour to the one when allow-dynamic-record-sizing is enabled, we still see most TLS records on 2K - 3K range but we also see much larger records as seen below:
And here's the breakdown from the capture on Wireshark:
At first glance, this might not seem a massive improvement but this is just for demonstration purposes as I wanted to limit the size of my packet capture.
However, the larger the file and the longer the connection time, the 5k+ TLS record size would adapt and increase accordingly.
Appendix - About Lab Test Counters
BIG-IP's counter is very accurate but I'd like to clarify that I used number of filtered displayed packets as the counter used for my Wireshark tables above.
This is why we see some difference when compared to TMSH output as TLS records that fit into a single TCP segment will still be bundled (encapsulated) into a single TCP segment.
For example, frame number #6 below has 3 TLS records of size 81, 1047 and 4 bytes respectively:
Notice that I have also created a column on Wireshark to make it easier for us to visualise the TLS Record Size without having to dig deeper into headers and used a Wireshark filter (ssl.record.length >= 0 and ssl.record.length <= 1000) to display only TCP packets that contain TLS records of size > 0 and <= 1000 bytes.