Any questions? Post'em

 

You mention TCP/HTTP, so I'm guessing this is XML being transported over HTTP. If that's the case, then no BIG-IP tweaking should be required for normal clients/servers.

 

 

Unless you ask BIG-IP to do otherwise, it'll treat XML responses just like image responses or web pages or zip files, or anything else. 60KB isn't even that big. :)

 

 

With regards to the magic size, I suspect this has something to do with the client or server. The closest magic number on BIG-IP is 32768, which is the maximum size of HTTP headers we'll accept by default (this is configurable on the HTTP profile).

 

 

Your comment about SSL packet size (actually SSL record size) is likely the key. BIG-IP will attempt to send large SSL records because it's normally in the best interests of all that are involved (it's faster for both BIG-IP and receiving devices to deal with fewer large SSL records than many small records).

 

 

Whether BIG-IP is going to use large records or small records depends on the speed of the clients and servers (how quickly we're getting data from the server and how quickly the client can receive it from us).

 

 

It's very normal to see multiple SSL record sizes used throughout a single transaction. With that in mind, if the client really cannot accept 16KB SSL records, then it seems reasonable to think that the 19KB magic number could actually be a combination of a 1 or few small records (1KB-4KB) and perhaps followed by a 16KB record which doesn't work.

 

 

It would be very unusual for a device to not support 16KB records, but if that really is the case perhaps the problem could be worked around by limiting BIG-IP's TCP 'send buffer' parameter on the TCP profile, or perhaps reducing the 'proxy buffer high' to something small like 4096. This is just a guess, I don't have an easy way to test this.

 

 

Given your situation, I encourage you to contact the F5 Networks support team to work through the issue.

 

 

Good luck!

 

 

Mike Lowell