Video conference performance drops

What do you see if you do tcpdump on eth0?  And then on eth1?  Are packets lost inside your network or before they reach you?

Did you learn anything from trying Sachin's suggestion?

Cheers - Bob

Below is a screenshot of some of the tcpdump output. One thing that stood out to me was the amount of packets without a listed length, could this be part of the problem?

I also ran an ifconfig before and after these tests, there was no jump in collisions or drops. There is only 1 collision shown by ifconfig which seems acceptable.

I also ran a iftop command on both interfaces to monitor bandwidth usage during the video conference. The second last column on the right (avg bandwidth per 20 seconds) showed 600Kbp~ DL and 65Kb~ UL to and from Zoom servers. Upload is noticeably bad here.

During all these tests I had the IPS Exceptions enabled

Hey Sachingurung,

As per my latest reply to BAlfson, I have used ifconfig while running the video conferences and there was no increase in dropped packets or collisions. 

I havnt used the wget command yet though. Am I safe to download a file to the main directory or is there a particular folder within the Sophos that I should browse to before downloading a file? 

Thanks!

Suggest you study RFC 3449 to see if your asymmetric network speeds could be causing or contributing to the problem.

In the US, the Verizon.com speedtest used to provide a "FIOS optimizer" link, which tweaked the settings but did not explain what it did.   It helped some.   However, I cannot find it tonight.   The relevant networks were small (5 or fewer devices), which higher asymmetry.

The usual approach is to put things in the /home directory unless they're large.  In this case, you could test with a 100MB file and then delete it from /home when you're done.

Strange that there are those zero-length packets without ports.  What do folks in the Zoom online community say about your packet capture?

Cheers - Bob

I haven't engaged Zoom support but certainly can reach out to them.

I also just downloaded a 120Mb file to the Sophos which downloaded at 7.68M/s (15 Seconds)
I feel like I should be seeing faster downloads speeds.  I checked the Sophos Web Admin to see how much activity there was at the time of downloading the file, we were using less than 2Mbps. Speed tests show I can get up to 50Mbps+ DL.

You said your connection is 65 Mbps - 7.68 MB/s is faster than that...

Cheers - Bob

Ah ok, I wasnt sure if the M stood for Megabits or Megabytes. Either way ill check in with Zoom support

So ive talked with Zoom support and they dont see any issues on their end. During my testing with them I put one of the 3 computers onto a completely separate network and WAN connection, the issue still occurred. Zoom recommended I contact our ISP but I dont think thats really the problem as we arnt pinning our available download bandwidth. I dont expect that they would be throttling Zoom and certainly not UDP traffic. Ill start running some WireShark captures to see if I can notice any other oddities.

Ok so I've made some interesting discoveries but still no solution to this.

In my testing I have put two devices on a completely separate WAN\Network and then left one on our main network while running some test meetings. 

Once the 3rd device joins the meeting, Zoom clients shift the meeting from each other's WAN IP's to Zoom servers. Its at this point that I notice a large amount of OUTBOUND Packet fragmentation as seen in the screenshot. It gets to the point where every second OUTBOUND UDP packet from our network is fragmented and reassembled. Inbound packets are not fragmented nor is there a drop in external video quality.

I adjusted our WAN MTU as I noticed that it was set to 576 for some reason, its now 1500 but still no luck.

Before the 3rd device joins the meeting there is little to no packet fragmentation and packet lengths can be 1100~ (bigger than some packets sent during the 3 person meeting).

WireShark Packet captures in a completely separate network show none of this fragmentation.

Any other thoughts?

Thanks!