Hello, I am working on an experimental network and analyse the congestion window using tcpprobe and I notice that the congestion window drops periodically and no duplicate acks, or timeouts are seen at the sender in my wireshark trace. This does not fit with the TCP congestion window theory. I am using the default congestion control algorithm in linux, cubic. Is there a Linux implementation which allows the congestion window to drop when it is larger than ssthresh? Ideally the channel capacity is 100Mbit and the video traffic is 2Mbps, which should not lead to packet loss. I am not sure if wireshark drops some packets. Any thoughts on this is highly appreciated! Thanks in advance! Tilak asked 02 Feb '16, 07:32  Varisetty edited 03 Feb '16, 08:00 |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Knowing nothing about your capturing machine (hardware, OS, process load), it is hard to guess whether Wireshark is dropping packets or not. But try using tcpdump (if on linux) or dumpcap to store the captured packets into a file without analysing them while capturing; not only that these applications lower the CPU and memory load as compared to Wireshark or tshark, but they would also tell you whether they have failed to process some packets due to lack of CPU power or memory. They won't tell you, however, about packets that haven't even reached them.
On Windows, there are many security applications known to affect WinPcap's ability to see all packets (search this site for details); on Linux, I could think about some rate limiting setup of tc to limit the throughput beyond the congestion control of the tcp stack itself, but not Wireshark's/tcpdump's ability to capture the packets which have really passed through the network adaptor. TCP processing offloading (chimney) may be responsible for not showing all packets to Wireshark at both OSes - again, look around at this site for this type of issues.