Bandwidth estimation wifi vs ethernet?

Good morning,

Can I ask is there any difference in how bandwidth estimations work on wifi vs wired ethernet?

Reason for asking is in our customized environment we are hitting some strange issues where on a p2p call after a few minutes the upload bandwidth estimation of one of the two devices is sharply dropping from 2.5mb upload to 64kbps upload and then staying there, which then causing quality problems on the far side.

Specifically it seems to happen on wifi calls across different networks. We are testing with the devices near the router and not too many devices on the network. On-net wifi on same network seems to be fine. Also ethernet across the same networks is fine. No firewalls are present in our test.

Of course I understand wifi will perform differently to wired. But seems like strange behaviour.

We can’t replicate jitsi meet public or beta URLs yet.

We are still investigating what it may be.

Thanks
Daryl

Normally in a Jitsi p2p call, the media traffic flows directly between the endpoints, without traversing a jitsi videobridge.

Is that also the case in your customized environment? If so, this behavior is entirely Chrome’s; in a direct call, Jitsi’s code doesn’t have anything to do with the bandwidth estimation.

If you have your environment configured to use the JVB even in a 2-party call, then this is a scenario we haven’t tested a lot (as mentioned, we don’t usually do this). Are you using the new jvb 2.0, or the old bridge?

Hi Daryl,

As far as I know the same algorithm is used regardless of the network, though different network types have different characteristics. The wifi MAC layer uses retransmisions, and that looks to higher layers as large spikes in jitter.

What I find very suprising is that you can not repro it on meet.jit.si or beta. I can’t think of any difference that can impact P2P in that way (unless your client modifies P2P signaling somehow?). Were your tests using the same browser versions? I would suggest also testing with appr.tc.

Regards,
Boris

OK, was able to duplicate the p2p bandwidth estimation upload issue on https://meet.jit.si/csq123 on Sunday Feb 9th at 21:51 UK time.

Admittedly the site with the upload issue is on a pretty terrible airbnb home wifi network, but still, it should be uploading more than 62kbps.

some screenshots here…

Any thoughts on what it could be?

I’ll do a more scientific test after next week too.

Thanks
Daryl

another strange observation with this p2p issue, it appears that its only one device that has the dramatic bandwidth estimation upload speed drop. The other device bandwidth estimation remains stable.

I have the same problems in p2p call , 2 notebooks with Chromium in WIFI.

Jitsi team, do you think this could be a chrome / chromium issue then do you think?

It’s possible that there was loss in the network, leading to the bandwidth estimation dropping (i.e. it worked as designed). A speed test might not necessarily catch this.

It’s also possible that it’s something in Chrome, that’s why I suggested trying appr.tc.

Boris

Hi @Boris_Grozev and @Jonathan_Lennox.

Now I’m back at my desk we’ve done some more testing and got some consistent results worth investigating.

For the test we used…

  1. PC on wireless home network in Singapore (no firewall)
  2. PC on wireless office network in UK (no firewall)

tested…
Video Window dev (customized jitsi using latest unstable with 2 location servers with OCTO)
Video Window prod (customized jitsi using latest unstable with 4 location servers with OCTO)


https://.meet.jit.si/
https://appr.tc/

So we can duplicate the issue on Video Window dev and prod, also beta.meet.jit.si. The Singapore device constantly drops the upload bandwidth estimation after a few minutes and stays poor.

However, we cannot duplicate it on meet.jit.si or appr.tc. These stay at the correct 2mb bandwidth estimation and stay good quality connections on both sides.

So to me, it sounds like something has changed in the unstable jitsi code that may be causing a problem for p2p.

Can you please look at the logs for https://beta.meet.jit.si/csq123 and https://meet.jit.si/csq123 for todays date Monday February 17th and see what you find.

Also I’m happy to jump on a live call and troubleshoot or take wireshark logs too if you wish.

Thanks
Daryl

I noticed both PC’s were on chrome 79.x, so I updated them both to chrome 80.x. Can’t seem to replicate the problem now which is strange. Hopefully a good strange. I’ll keep trying to test.

We spent some time trying to trace a very similar problem last week and updating from Chrome 73 to Chrome 80 fixed it for us. This was on a deployment running jvb 1.0. We still don’t know what caused the problem and it seemed to have started occurring only recently.

Regards,

Boris

Seems that chrome v80 is not solving our p2p problem. This one is also ethernet to ethernet. I’ll keep digging. Is there any updates on the jitsi side regarding this upload quality drop? Thanks

I replicated the p2p problem on https://beta.meet.jit.si/nuub123 on the same two ethernet devices on chrome v80 today Thursday 20th February if you want to check the logs. Thanks

However, I am unable to duplicate on https://meet.jit.si/nuub123 if you want to compare the logs

hi there, did you get a chance to take a look at the logs yet? Thanks

We double checked our infrastructure settings, turns out we had H264 configured for p2p. We’ve changed this back to VP8 and initial tests look positive. We’ll keep testing overnight.

Have you heard of H264 causing this kind of problem before?

Thanks