Forum Discussion
Hi,
Not an expert here but maybe changing Proxy Buffers for TCP connection based on mentioned client headers could be the choice? If you lower proxy buffer high then after receiving small part of the reply BIG-IP will send ser window, and probably will resend it (or maybe TCP keep alive will have to be used on serverside - via profile config) so IIS TCP connection will not timeout and there will be no reset from IIS.
- TCP::proxybuffer - sets the TCP proxy buffer thresholds
- TCP::proxybufferhigh - gets the proxy buffer high threshold
- TCP::proxybufferlow - gets the proxy buffer low threshold
- TCP::sendbuf - sets the TCP send buffer size
Maybe as well manipulating receive window on serverside could be used
TCP::recvwnd - sets the TCP receive window
BTW: quoting TCP gurus on DevCentral:
- proxy-buffer-high = send-buffer-size = (clientside bandwidth) * (clientside RTT)
- proxy-buffer-low = (clientside bandwidth) * (serverside RTT)
- proxy-buffer-low must be sufficiently below proxy-buffer-high to avoid flapping.
Those commands probably can be used to estimate clienside RTT to be used in calculations above:
- TCP::rtt - Returns the smoothed round-trip time estimate for a TCP connection.
- TCP::rttvar - The measured RTT variance in units of "1/16 of a millisecond".
Don't know how to estimate clienside bandwidth in easy way - maybe just be Wireshark analysis on big enough sample.
Or maybe (if Analytics profile is assigned to VS) by qurying stats collected - maybe like described in Getting total bandwidth currently utilized in an iRule
Piotr