tmcgov05 wrote:

> A packet capture shows an Active FTP session riddled with tons of TCP
> Duplicate Acks by the receiver and subsequent Retransmissions by the
> sender (CCC).... no wonder the user experience was very poor. However,
> although we have been able to identify the symptoms, the root cause has
> eluded us

It sounds like the root cause is packet loss. Where is your sniffer
located?

> Our analysis shows that the sender appears to be properly
> transmitting his FTP Data packets, but the receiver is sending a normal
> ACK followed immediately by a DUP ACK.

A dupACK is a normal ACK. It's just *another* normal ACK.

The fact that you're seeing the data sent correctly indicates that
nothing is wrong with the sender, nor with the network equipment up to
the point of the sniffer, but that packets (segments) aren't correctly
arriving at the receiver. Either the network isn't delivering them, or
the receiver can't hear them.

> This ongoing "paranoid" behavior
> by the receiver results in Retransmissions by the sender, thus clogging
> up the flow with a snowballing effect.

The receiver isn't paranoid. He's telling you that data isn't showing
up in order.

Congestion control on the sender should prevent a snowball effect. The
overall packet rate should be very low when dupACKs are rolling in.

> The strange thing here is that according to the timestamps, there is no
> need for the receiver to be sending a DUP ACK because there appears to
> be no delay whatsoever. So what else would cause the receiver to feel
> the need to send a DUP ACK if there was no obvious delay ?

dupACKs are not a product of delay. They're a product of
missing/misordered segments.

Try deploying two sniffers: one very close to the server, the other
very close to the client.

See if all client-bound packets observed by the server sniffer are
observed by the client sniffer.

/chris