Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Strange TCP duplicate ack/retransmission problem

We have an ATM link between Chicago and an office in Baroda, India. Latency on the link is about 260ms RTT. File transfers from Chicago to Baroda take much longer than transfers from Baroda to Chicago. We analyzed a trace of the slow transfer from Chicago to Baroda and observed the following:

All downloads to the Baroda PC, whether using FTP, HTTP, or PCATTCP, experience a large number of duplicate acks and retransmissions throughout the entire transfer. Two packets get sent from Chicago to Baroda. Baroda sends an ack, acknowledging receipt of only the first packet. A third packet gets sent from Chicago to Baroda. Baroda responds with a duplicate ack, acknowledging receipt of only the first packet. A fourth packet gets send from Chicago to Baroda. Baroda again responds with a duplicate ack,acknowledging receipt of only the first packet. Chicago now retransmits packet number two to Baroda. Baroda responds with an ack, acknowledging receipt of all packets up to and including packet four. This behavior repeats over and over again until the entire file finally gets transferred to Baroda.

The ATM link is a 4Mb link, and the ATM provider has verified the SPVC is symmetrical. The Baroda side of the ATM link uses 4 E1 ports with IMA. The Chicago side of the link uses a DS3 interface.

The duplicate acks and retransmissions feels like a congestion problem, except that we don't have enough traffic on the link yet to cause congestion.

Does anyone have any suggestions as to how we can pinpoint what is causing this pattern of duplicate acks and retranmissions?

1 REPLY
Blue

Re: Strange TCP duplicate ack/retransmission problem

i would verify what the interface queues are showing. packets/drops, etc. also check for CRCs or packet errors on the interfaces.

do you have inbound acls/firewall, etc at baroda that would induce any delay?

triple check your speeds and perform a packet debug if you can. (off hours would be best to not impede performance during office hours)

526
Views
0
Helpful
1
Replies
CreatePlease login to create content