Problem with 0 Byte TCP Window over MPLS but not over Frame Relay

[baskervi]

We have an application that's been running for years over frame relay with no problems. We recently moved over to MPLS, but now our main application consistently breaks after running a few minutes. What happens with the MPLS connection is that the windows size starts at 65535 and continues to decrease until a window size of 0 is seen. The last 50 packets we see are either "TCP ZeroWindowsProbe" or "TCP ZeroWindowProbeAck", which finally ends with a RST. We change back to frame, and this problem doesn't recur - the window size is properly maintained. We've called AT&T, and they've said there is no QoS or policing enabled. The server is not overly busy either, so there isn't any reason why the server would limit the window size. We've done packet captures on both sides to compare the packet captures to see if anything was modified in transit, and the packets appear to match up perfectly.

I've done a cursory look of flags and tried to compare the packets between frame and MPLS, and I can't find any difference, but obviously there is. Has any one else run across this?

Thank you.

[lgijssel]

How do you get from 64k window to zero in a few minutes?

This sounds like a serious packet loss problem.

New mpls network, high packet loss, providers....

Can you check the speed/duplex settings for CE/CPE?

Providers often fix these settings. When you are doing auto you will lose lots of packets.

Sorry but this was the first thing that crossed my mind when trying to combine the facts provided.

When the problem is more complex (likely) we need more details.

regards,

Leo

[baskervi]

There aren't any packet losses and very few retransmissions. I see the sequence numbers increment and the appropriate acknowledgements as expected. Doing a ping with "ping -l 1472 -f 172.16.11.10", which is the remote host, doesn't yield any timeouts.