cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.

Introduction

This is what we're going to talk about today:0151T000002dlZeQAI.png

Under normal circumstances (Allow Dynamic Record Sizing unticked on 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:

0151T000002dlZpQAI.png

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:

0151T000002dlaOQAQ.png

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:0151T000002dmASQAY.png

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:

0151T000002dlaXQAQ.png

And here's the breakdown from the capture on Wireshark:

0151T000002dlahQAA.png

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:

0151T000002dmAIQAY.png

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.

Version history
Last update:
‎05-Jun-2020 01:55
Updated by:
Contributors