High rate of TCP ACKs

[m.athif]

We are offering Internet on VSATs, the VSAT backbone supports TCP spoofing. All the traffic from the remote VSATs land on F1/0 interface of 7206 router 12.2(7)c IOS, F1/1 has a connection to ISP backbone.

We are noticing that most of the traffic is contributed by TCP ACKs. Please suggest a way to reduce the TCP ACKs.

SITHUB#sh tcp stat

Rcvd: 29997 Total, 0 no port

0 checksum error, 0 bad offset, 0 too short

5993 packets (50171 bytes) in sequence

1 dup packets (1 bytes)

2 partially dup packets (2 bytes)

0 out-of-order packets (0 bytes)

0 packets (0 bytes) with data after window

0 packets after close

0 window probe packets, 0 window update packets

0 dup ack packets, 0 ack packets with unsend data

6782 ack packets (1003566 bytes)

Sent: 9004 Total, 0 urgent packets

307 control packets (including 0 retransmitted)

8447 data packets (1003564 bytes)

23 data packets (4515 bytes) retransmitted

0 data packets (0 bytes) fastretransmitted

226 ack only packets (169 delayed)

0 window probe packets, 1 window update packets

1 Connections initiated, 1 connections accepted, 2 connections established

2 Connections closed (including 0 dropped, 0 embryonic dropped)

23 Total rxmt timeout, 0 connections dropped in rxmt timeout

268 Keepalive timeout, 268 keepalive probe, 0 Connections dropped in keepalive

SITHUB#sh int f1/0

FastEthernet1/0 is up, line protocol is up

Hardware is AmdFE, address is 0002.4a18.a81c (bia 0002.4a18.a81c)

Description: <----- BIT Ethernet Link ----->

Internet address is 192.168.1.20/24

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 6/255, rxload 2/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, 100BaseTX/FX

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 01:57:55

Input queue: 0/30/654/5903 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: random early detection(RED)

5 minute input rate 803000 bits/sec, 619 packets/sec

5 minute output rate 2546000 bits/sec, 534 packets/sec

5967862 packets input, 1194833399 bytes

Received 311475 broadcasts, 0 runts, 0 giants, 654 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog

0 input packets with dribble condition detected

4671847 packets output, 3152771679 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

[rais]

Though I am not sure, but I am still replying to this message because I am more inclined towards surity:

1. These ACK packets (6782 in number above) are packets piggybacked with data. They are not JUST ack.

2. These are stats for router TCP process not those of hosts' data through the interface. Telnet to the router and you will see Connection Accepted incremented by one.

Thanks.

[m.athif]

Thanks. We had used sniffer in between and found that 50 % of the traffic is < 60 bytes ( Acks). I am not sure if these were piggybacked. We were trying to correlate this with router stats.

Our worry is the high no. of ACKS. Is there a way out to reduce these.

[rais]

How much is approximate round trip delay?

Which one is higher your sent-ACKs or received-ACKs?

Do you see any re-transmissions?

Did you try tuning your timeout thresholds?

Thanks.

[m.athif]

The round trip delay is more than 1 sec ( 2 satellite hops to access internet).

Whenever a remote VSAT tries to access any URL, the server sends 2 full segments of data and requests for an ACK. The client at the remote VSAT send backs the ack. If the Window size agreed between server and client is 64K ( Win2K window size default) with 1500 MTU, then after 40 frames an ack is supposed to be received , but why after 2 segments an ACK is requested ?.

The received-ACKs from the remote VSATs are more ( seen at the central router). There are no much retransmissions.

No I have not tried tuning any timeout thresholds.

Thanks.

[rais]

Win2K has default tcpWindowSize of 8760 octets. 0xFFFF or 64K is the max. it can go.

http://www.winguides.com/registry/display.php/268/

Are you using 64K window size?

Do you have duplicate ACKs? Is sending and receiving speed asymmetric? Is it ok to assume you are receiving more data than what you are sending?

Thanks.

[rais]

As per microsoft, default for Win2K is 17520 octets:

http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/reskit/en-us/regentry/58813.asp

Another useful link:

http://www.faqs.org/rfcs/rfc1323.html

Try making your window size 1Gb.

Rais.

[m.athif]

Thanks Rais. You are right the VSAT links are Asymmetric the send is very low compared to receive ( typically for http application). There are few duplicate packets but are very low.

I was mentioning of the default window size if somebody uses Win2k then it would be 64K ( we cannot change the window sizes to 1 Gb, because this requires a field visit ). Can we do someting at the router end ?.