[Randy.Grein@xxxxxxxxxxxxxx]

Roland,
A couple of things I noticed:

You mention 'several customers'. That makes individual machine problems 
less likely, although still possible. You still need to rule them out 
because that's easy - but I disagree with James' advice to exhaust your 
local options before engaging the carriers. Carrier problems are more 
common than they like to admit. More problems are caused by 'working as 
designed' rather than 'working as desired'.

Assuming you have solid local file transfers, consider round trip delay - 
VPNs over public networks are, or should be notorious for erratic round 
trip delay. This could be a case of localized congestion and you'll never 
find it without help from the carriers.  Also check your firewall tunnels 
- the firewalls should be able to give you dropped/delayed packet 
information for the tunnel. Trying to diagnose a tunnel from the inside is 
frankly a waste of time. Of course, unless you have a QOS guarantee from 
end to end and traffic stays on one carrier's network the entire time 
there's little that can be done to reduce the retries without 
renegotiating the contract. Internet traffic delivery is best effort.

There are still a few things you can do. Easiest is to adjust the TCP 
timeout/retry counters on the machines involved. Yes, it's a registry hack 
on Windows, but that's just poor design on Microsoft's part. You can have 
them reconsider the file transfers - time them during a slow part of the 
day (night), or reduce the amount of data involved. Otherwise renegotiate 
with your carrier. I had a customer last year (Internet VOIP provider) who 
had similar problems. Their carrier insisted the problem was on our end, 
and it took a long time to prove otherwise. They were jacking traffic all 
over the place, with different kinds of traffic going in different 
directions. The VOIP traffic sometimes went through San Jose, and that 
particular circuit was saturated by the after-school crowd resulting in 
audio fuzz, echo and dropped calls. We finally found this with, IIRC 
What's Up! Gold (to trace the connection to the VOIP services at the other 
end), comparing with traceroute at the same time. When we brought in 
another carrier they admitted they could upgrade our class of service, 
just that it would cost more.

Randy Grein
Network Engineer



"Roland Volz" <rvolz@xxxxxxxxxxxxxxx> 
Sent by: wireshark-users-bounces@xxxxxxxxxxxxx
06/04/2007 01:10 PM
Please respond to
rvolz@xxxxxxxxxxxxxxx; Please respond to
Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>


To
<wireshark-users@xxxxxxxxxxxxx>
cc

Subject
[Wireshark-users] TCP Dup Ack






I have a couple of customers that have been complaining of issues on their 
circuits, an issue that causes them to have problems with large file 
transfers. The only noteworthy problems in their data streams seem to be 
TCP Dup Acks – I’ve seen as many as sixty, or over a hundred, in file 
transfers of 100 MB test files. However, as near as I can determine, these 
errors are being introduced in the Internet, outside of our network (the 
customers use VPNs over internet circuits with major carriers for these 
file transfers).
 
As I said, we’ve tested our own network thoroughly, but I’m at a loss as 
to where to go with this issue. Obviously, telling the customer, “It’s not 
our fault” is unacceptable, as that doesn’t move them any closer to 
error-free file transfers. On the other hand, I’m not sure where to tell 
the carriers’ help desk technicians to look for the source of this issue. 
Has anyone seen this before on Internet circuits, and is there some way I 
can use Wireshark to help pinpoint the issue more specifically than 
telling the carrier, “It’s in your cloud”?
 
Thanks,
 
Roland Volz
Network Engineer
Data Access/Datapatch, Inc.
40 Eisenhower Drive
Paramus, NJ 07652-1404
(201) 843-5468 x7032
www.Data-Access.com
 _______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users



- -------------------------

CONFIDENTIALITY NOTICE: The information in this message may be proprietary and/or confidential, and is intended only for the use of the individual(s) to whom this email is addressed.  If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this email and deleting this email from your computer.  Nothing contained in this email or any attachment shall satisfy the requirements for contract formation or constitute an electronic signature.