at this moment my ltm is using 'High Speed'. when there are heavy packet loss, the retransmission timeout goes to 32 seconds, and sometimes goes to 64 seconds. And this causes a whole transaction takes more than 4 minutes to finish, which usually just needs 2 seconds. Wondering if 'Scalable' will be better? Can the maximum retransmission timeout be set to lower value?

I'm not sure any congestion control setting is going to help where there is 'heavy packet loss'. What's causing that loss? You can modify the TCP Profile and reduce the number of retransmissions from the default of 8 to something lower but of course this means your application will have to handle the data loss. I think it's standard (i.e. in the TCP/IP standard and thus not configurable) for the time between each retransmission to be double that of the previous one, so a value of 4 for instance would probably result in retransmission after 1s, 2s, 4s and finally 8s. You might want to investigate the other options in the TCP Profile as some of these might also be beneficial, however, I'd suggest you ultimately need to resolve the root cause of the packet loss.

thanks. definitely true it needs to figure out the packet loss ultimately. but it is in the network of my vendor, I can not even traceroute to them. (really secure!) before that, packet loss has to be mitigated. Is there a way to tune the maximum 64s of retransmission interval to 8 seconds? Scalable is said to be better, but i cannot find a doc about that.

Fair enough. To reduce the maximum retransmission interval to 8s you'll have to modify the default TCP Profile (or ideally create a new custom one) and reduce the number of retransmissions from 8 to 4. This will result in a max retransmission interval of 8s but obviously means only 4 retransmissions are attempted and past that the source client will have to retransmit or recover as appropriate. There's no way to independently modify the retransmission interval alone, as far as I'm aware.

tcp profile for heavy packet loss

13 Replies

szkwg_89687
Nimbostratus
Oct 18, 2012
"Maximum Segment Retransmissions" was kept at 8 times. when keepalive is set to 8 seconds, the times of retransmission seemed to be cut to 3 times (i think so, it is a bit hard to simulate packet drop in lab env ). As the app is web-based, it is not easy to tune the app to send another request. Apologize I did not make the situation more clear. Keepalive is chosen because packet loss could be bidirectional, i.e., data packets and some of its ack, I would like to have keepalive packets flowing to have acknowledge number showing up.

Under normal circumstance, RTT is 40ms, data to transfer is about 160KB. basically it is a packet loss burst, within one window several packets got dropped. Yes, retransmissions are timeout based. at first, i was thinking to use new Reno, but it seems the interval of retransmission still went up to 32 sec or 64sec. As the interval turns to so large, I did not notice/calculate smoothed RTT.

I will learn more about wom-tcp-wan-optimized. tcpdump part, I will try to replace ip and upload.
szkwg_89687
Nimbostratus
Oct 19, 2012
how can I upload an attachment?
szkwg_89687
Nimbostratus
Oct 19, 2012
wom-tcp-wan-optimized seems to be very aggressive. it ignores multiple packet loss in a burst. it seems like to be used in a very reliable env for large data, long tcp sessions. is it right?

Forum Discussion

tcp profile for heavy packet loss

13 Replies

Recent Discussions

Rundeck ansible F5 errors

What is the meaning is 52% block in WAF

rewrite Azure AD response for portal access via web portal

AS3 Monitoring multiple ports selectively

Open Redirection Mitigation

Related Content

Decrypting BIG-IP Packet Captures without iRules

Decrypting BIG-IP Packet Captures Automatically

Automating Packet Captures on BIG-IP

F5 packet buffer

UDP TCP Packet Duplication