cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1333
Views
0
Helpful
13
Replies

Window size issue on SSL module with CSS/ACE

michael.e.reid
Level 1
Level 1

Hello,

We have a problem in our production environment when uploading files through the SSL module, this was due to a fixed 12K window size on the module. In 8.10 this can be resolved as the window size can be increased to 41K.

Now, we are testing the ACE blade at the moment and I have just discovered this has a window size of 17.4K so poorer performance than CSS with new S/W.

Is this window size on the ACE configurable ?

cheers,

Mike

13 Replies 13

Gilles Dufour
Cisco Employee
Cisco Employee

Mike,

sorry for this late response but I was actually trying to collect information.

Currently there is no command to change the window size with ace.

However, we would like to know if you really measured better performance with CSS vs ACE or you suppose it will be worst on the ACE module because of the window size ?

If you measured better performance with the CSS, could you share the config you did use on CSS and ACE and also let us know what tests you did.

Thanks,

Gilles.

Hi Gilles,

I measured better performance with CSS with the 'ssl-server x tcp virtual window' and teh 'ssl-server x tcp server window' commands configured.

We have a service that suffers from poor performance when uploading documents through the SSL module due to the fixed 12K window size.

I configured a rule to a test server via the SSL offloader and measured the time it took upload an 8Mb file with different simulated latencies.

With the window size commands the CSS upload was circa 3x quicker than the CSS without the window size commands, this is expected.

With the ACE there was a improvement in upload speeds but not to the same scale - for comparison the upload speeds over a 150ms latency were 50s for CSS and 113s for ACE. The CSS without the window commands was 145s.

I captured with ethereal and saw that the window size on the CSS was 40960, which I had set manually, and on the ACE it is 17408.

For the ACE I captured on both client and server side, the window is 17408. For the CSS I have only captured on the client side so far but can see the 40960 window size.

I can share the config if you like, it was nothing too complicated. However, I feel the issue here is the window size been advertised by the SSL card. That will always cause an issue over higher latency links.

cheers,

Mike

Mike,

I did my own tests and other developpers showed me their tests, and the ACE module is always faster than the CSS.

The worst scenario is ACE being only 5 times faster than the CSS.

Best scenario, ACE is 10 times faster than the CSS.

I'm not sure what is different in your setup.

Maybe you should submit a service request to have the TAC look into your config.

Capture sniffer traces with CSS and ACE as well so we can compare.

Gilles

Gilles,

I already have some sniffer traces but they are too large to attach unfortunately.

Can you confirm what window size you see the ACE as advertising ? What was the latency for your test ?

cheers,

Mike

Gilles,

Any update, can you confirm what window size is seen when uploading documents to a server behind the ACE, and when using the SSL daughter card for encryption/decryption.

cheers.

Mike

Mike,

the window size with ACE is fixed at 17.4k.

But even with this size the ACE module is much faster than the CSS with window size of 40k

Gilles.

Gilles,

Really ? Can you confirm that uploading a document to a server behind the ACE, also using front end SSL, and with a latency of 200ms from client to VIP is quicker than with a CSS configured with 41K window ?

This isnot what I see in our environment ?

I didn't have 200msec latency.

Let me see if this factor can be added.

Gilles

Michael,

to move forward, could you please open a service request with the TAC and provide your test configs and sniffer traces showing the download with ace and with css.

you can limit the packet size of the captured frame to include only ip and tcp headers.

Thanks,

Gilles.

I'm late to this thread.

For what it's worth, you can set ACE to allow window scaling between client and server. But since the ssl-proxy window is fixed at 17.4, that's not much help unless you want to do away with SSL offload.

parameter-map type connection BIGSTUFF

set tcp window-scale 2

tcp-options window-scale allow

policy-map multi-match VIPS

class VIP-APP-WEB

loadbalance vip inservice

loadbalance policy APP-POLICY

loadbalance vip icmp-reply active

connection advanced-options BIGSTUFF

-Craig

Hello,

I've tested the SSL Engine of the ACE also.

Compared to a webserver, it seems to be slower if large files are to be downloaded.

I've generated a 100 MB File for testing.

With the ACE i get about 100-200 KB/sec

With the Webserver directly i get about 10 MB/sec.

I've traced a little bit and found out two things

1) The Window-Size on the ACE is smaller

2) The SSL-Record Layer is 16k by the Webserver and only 1440 on the ACE Module.

In the past, we had also this Problem on the SSL Module from the CSS. There was introduced a knob for setting a SSL-Queu-Delay.

I think, this + the window Size is missing on the ACE Module.

Sven

I upgraded my blades to 1.4j a developer release today and i think that the problems you described are fixed there.

While sniffing and decrypting ssl traffic on my quite slow machine i still get 2MB+/sec when downloading a 100mb binary garbage file. So i think this issue will imho get fixed with the next release.

Edit: The window size is still exact 17408 bytes on the aces. Unfortunately i can't compare the speed to the previous version.

Roble

Yes, you should test the latest sustaining image if you can due to the following bug :

CSCsi32632

SSL performance issue when posting large files

Gilles.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: