Re: TCP Dup Ack Issues with Comcast vs.Cablevision

[Martin Visser <martinvisser99 () gmail com>]

Not sure exactly what is going on, but if you are seeing duplicate ACKs from
the server (the one showed had a source TCP port of http, or I guess 80, so
I assume it is from the server), this like indicates the ACKs from your
client are not reaching the server in a timely fashion. Is there anything
you are doing to cause outbound congestion?

In order to some basic testing I would try to get an understanding of
round-trip delay to your local LAN, your service provider and then on to
your target server. This might help you understand where the bottleneck is
occurring. You do this during your trials by simple ICMP ping, or even
better use a tool like tcping or hping to more easily measure the
SYN/SYN-ACK response time. Doing this simultaneously will and plotting the
variation with throughput will guide you to the contributary cause.

Just remember that all 802.11 wireless networks are "virtually" full-duplex
but physically half-duplex in nature. In essence the radio can only transmit
OR receive at any one time.

(Way back doing 802.11b testing I could get 6Mbps down/0Mbps up, or 3M/3M or
any combination).

Also 54Mbps is the physical throughput, with encoding and error connecting,
the available bandwidth to IP traffic is going to be only about 25Mbps.  (In
my testing above at 802.11b 11Mbps carrier, the actual goodput was 6Mbps).

Regards, Martin

MartinVisser99 () gmail com


On Sat, Feb 27, 2010 at 3:57 AM, William Howard
<whoward () spotonnetworks com>wrote:

>  I didn’t want to clutter up the e-mail with all of the different things
> that were done to eliminate the wireless AP/wireless speed as the source of
> the problem.  The AP is set to G only and we used a sniffer to eliminate
> other sources of interference including 2.4 Ghz phones and the like.  As
> mentioned below, we are connected at 54 Mbps with a “good” signal.  The APs
> we tested were plugged directly into the circuit but it didn’t matter if
> they were plugged directly in or if they were through a router.  It also
> didn’t matter which manufacturer of the AP/Router was used (Linksys – 3
> types, Colubris/HP -2 Types, and Netgear -2 types) – the symptoms were still
> the same.
>
>
>
> We did setup a “mini-Speedtest” server using the available software from
> SpeedTest.net – we did not see the speed issues when going wireless or wired
> to that server – regardless of what equipment was put in-between the
> wireless client and the server.  This is one of the things we did as we
> honed in on the fact that this issue was only present at Comcast sites –
> sites with Cablevision or other providers do not exhibit this issue.
>
>
>
> Until the registry settings were changed – the speeds were consistently 6-9
> Mbps.  After changing the settings – the speeds improved to 15-19 so the
> wireless speed is not the overriding factor.
>
>
>
> What is concerning me is the quantity of TCP Dup Acks seen in the traces.
> We have since done another test at another person’s home Comcast circuit
> that is 30/5 and on this particular setup – the TCP Dup Acks are not present
> and the speeds with/without the registry settings are equivalent at the
> 16-18 Mbps range.  So it appears that certain Comcast locations do not have
> this issue.  We have not tested at all of our Comcast sites but where we are
> seeing this is in the Connecticut and Massachusetts areas.
>
>
>
> My primary concern is the volume of TCP Dup Acks and why we might be seeing
> these given that they are present in both the wired and wireless traces at
> the sites where the wireless speeds are slow (without the registry
> changes).  Has anyone else seen this?
>
>
>
> Our initial conversation with Comcast for one site in particular went about
> as expected – basically they said if you are getting the speeds wired – go
> pound sand….
>
>
>
> I would have liked to believe this was strictly a wireless issue but the
> facts/tests point toward Comcast in several regions.
>
>
>
> William Howard
>   ------------------------------
>
> *From:* wireshark-users-bounces () wireshark org [mailto:
> wireshark-users-bounces () wireshark org] *On Behalf Of *Alan Emery
> *Sent:* Friday, February 26, 2010 11:36 AM
>
> *To:* Community support list for Wireshark
> *Subject:* Re: [Wireshark-users] TCP Dup Ack Issues with Comcast
> vs.Cablevision
>
>
>
> This may be more related to a setting on the wireless access point. If the
> wireless AP is not set to a fixed mode such as "g" or "n", and it "hears"
> the presence of a "b" device associated or not, it will go into a
> compatibility mode and effectively run at the lower "b" rate. In my SOHO
> environment, I fix my wireless mode to "g" as that is compatible with all
> the devices I want to have connected, but if a guest brings in a "b" mode
> device, they cannot connect, but they don't downgrade the throughput of my
> existing network. Your 6-9 Mbps throughput is more typical of what I would
> expect in a "b" environment.
>
> If you can isolate the wireless AP to a switch that will allow you to
> connect a local target device, or to switch ports on the AP if available,
> you can look at throughput just going through the AP to a local target
> device to see if the issue lies with the AP or not.
>
> Alan Emery
>
> IBM Global Solution Center
> 1177 S Beltline Road, Coppell, TX 75019
>
> [image: Inactive hide details for William Howard ---02/26/2010 09:32:29
> AM---We have been investigating what seems to be an obscure iss]William
> Howard ---02/26/2010 09:32:29 AM---We have been investigating what seems to
> be an obscure issue with regards to Comcast speeds wired v
>
>
> From:
>
>
> William Howard <wghoward () optonline net>
>
>
> To:
>
>
> wireshark-users () wireshark org
>
>
> Date:
>
>
> 02/26/2010 09:32 AM
>
>
> Subject:
>
>
> [Wireshark-users] TCP Dup Ack Issues with Comcast vs. Cablevision
>
>
> Sent by:
>
>
> wireshark-users-bounces () wireshark org
>   ------------------------------
>
>
>
>
>
> We have been investigating what seems to be an obscure issue with regards
> to Comcast speeds wired vs. wireless "G" speeds on a 30/5 circuit.
>
> Here are the symptoms:
>
> Wired (directly to modem): Speeds are what one would expect - 25-30 Mbps
> down and 4-5 Mbps up.
>
> Wireless: Speeds are in the 6-9 Mbps. We have tried a variety of consumer
> and higher end APs/Wireless routers. All with the same basic results - the
> speeds are significantly slower.
>
>     - The wireless NIC was connected with a "good" signal at 54 Mbps.
>       - I verified that wireless interference was not an issue.
>       - I tried several different laptops to make sure that the particular
>       wireless NIC was an issue.
>       - The AP/Router were the only items on the circuit. Time of day did
>       not matter as I tried going back and forth between wired and wireless - both
>       produced consistent speeds each time.
>
> What we did discover is that when testing the same equipment on a
> cablevision/optimum online 30/5 circuit, the problems virtually disappear.
> Wired speeds are equivalent to Comcast but wireless speeds were in the 15-19
> Mbps range.
>
> In order to dig deeper, I captured wireshark traces for both wired/wireless
> on Comcast and Optimum Online circuits. The biggest difference I could find
> is that on the Comcast circuit both wired and wireless, there were many: TCP
> Dup ACK packets (see below for an example)
>
> TCP [TCP Dup ACK 17802#55] http > apc-3052 [ACK] Seq=8154484 Ack=307815
> Win=206848 Len=0 SLE=370595 SRE=447975 SLE=331175 SRE=335555
>
> I have seen the "tcp optimizers" and they have produced good results and
> have improved the Comcast speeds to 12-16 Mbps but it seems very odd that
> only Comcast seems to suffer from packets arriving out of order (or whatever
> is causing this) but Cablevision does not. I don't like the idea of having
> to change a client device when it seems like this problem lies within the
> Comcast network.
>
> Has anyone seen this before? Is there a solution without changing the
> client laptop? We would like to have a solution that is hardware based
> (router or firmware) rather than telling users they must all make registry
> changes which makes us nervous (liability) and end-users irritated that "it
> works on other networks without a problem"
>
> Any insight on this would be greatly appreciated.
>
> Will Howard
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>
> mailto:wireshark-users-request () wireshark org?subject=unsubscribe<wireshark-users-request () wireshark 
> org?subject=unsubscribe>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe