Question about applying BBR on video streaming

[Aerys Nan]

Hello,

Recently I am studying different congestion control algorithms of video streaming applications. I noticed that WebRTC has implemented GCC, BBR, and PCC for congestion control. However, BBR was deprecated due to some "performance issues" and removed from the codebase. I tried to run those BBR codes and found the performance is not satisfactory.

According to the results of my experiment (see the figure enclosed), when BBR does an overestimation of bandwidth, the adaptive encoding module will increase the target bitrate for the encoder. This is very different from the bulk transfer, where an overestimation doesn't increase the total amount of data to be sent. The increased bitrate will cause congestion. When inflight data is bounded by CWND, the remaining data will be piled in the pacing queue, leading to an obvious lag between a server and a client.

But the experiment results conflict with the fact that YouTube is using QUIC-BBR right now. So I have several questions:

1. Are the same problems observed in QUIC-BBR?

2. Are there some obvious differences between WebRTC-BBR and QUIC-BBR?

3. Is there any open-source platform that has a successful implementation of BBR in video streaming? It would be much better if that platform has some corresponding tools that can directly test its performance.

Thanks a lot.

Best regards,

Nan

[Aerys Nan]

[Aerys Nan]

In the first figure, the red line is the bandwidth measurement result given by BBR. The blue line is the corresponding suggested encoding bitrate (given by the adaptive encoding module). The green histogram-like lines are the actual outbound bandwidth. The horizontal dotted line is the ground truth bandwidth.

The second and the third figure represent the corresponding RTT and pacing queue size. They together determine the lag between server and client.

By the way, I start the server and client on the same machine, only applying a bandwidth constraint to both applications using a third-party tool. So the RTprop is actually small. Does this scenario not being a "long fat network" influence the performance?

[ians...@google.com]

What you're describing matches some of the issues we saw.

One issue was slight bandwidth over-estimation, as you're observing.   Applying a max filter makes even small over-estimations fairly sticky.  As your graph shows, this was the worst in STARTUP, because the bandwidth estimate is limited to the sending rate, but the sending rate is notably higher than the bandwidth estimate in STARTUP.  It's possible we have a bug we never identified in our bandwidth estimator, but there's also a known possibility for over-estimates in the presence of ack aggregation.

In our testing, the fact that the flow went app-limited somewhat frequently could prevent bad bandwidth estimates from expiring as quickly as you'd like or existing STARTUP.  However, given you have a standing queue, it seems like that isn't a factor for your testing.

One final issue we observed was an inflated min_rtt estimate when using BBR in both directions of a WebRTC flow, particularly when it took a long time to exit STARTUP.

For YouTube video streaming, the queue is completely drained fairly frequently in virtually all flows, which means slight bandwidth over-estimates do not create permanent queues.  Also, the ABR algorithms are substantially different and adapt to observed delivery rates.

Ian

[Hu Damon]

I found some reason that posted in webRTC issues about why bbr is bad perfomance in webRTC. " To measure the bottleneck bandwidth, we need to build network queues. To accurately measure the RTT, all network queues must be completely drained which requires sending almost nothing for at least one RTT. These variations in target send rate do not play nice with encoders and jitter buffers  "。Discussion link is here.

And I'm wundering what kind of "third-party tool" you are using? When i use clumsy to applying a bandwidth, there's no buffer queue in it and will cause packet lost when there is over sending.Is it because I don't use it correctly?

[Neal Cardwell]

On Wed, Jul 12, 2023 at 11:51 PM Hu Damon <ds.sin...@gmail.com> wrote:

I found some reason that posted in webRTC issues about why bbr is bad perfomance in webRTC. " To measure the bottleneck bandwidth, we need to build network queues. To accurately measure the RTT, all network queues must be completely drained which requires sending almost nothing for at least one RTT.

The "which requires sending almost nothing for at least one RTT" part does not seem quite right. If the queue is small, then to drain the queue completely the sender needs only to send slightly lower than the available bandwidth.

To take a simple example, in theory, with an idealized wired link, if the sender's estimate of the available bandwidth is correct, and the queue starts out empty, then the sender could alternate between sending at 1.25x and 0.75x its available bandwidth, and have the queue be empty roughly once every two round trip times. Basically graphs of the queue depth and RTT would trace a sawtooth, with the bottom of the sawteeth being an empty queue in the queue depth graph and the min_rtt in the RTT graph.

best regards,

neal

 

These variations in target send rate do not play nice with encoders and jitter buffers  "。Discussion link is here.

And I'm wundering what kind of "third-party tool" you are using? When i use clumsy to applying a bandwidth, there's no buffer queue in it and will cause packet lost when there is over sending.Is it because I don't use it correctly?

On Tuesday, 23 February 2021 at 14:23:56 UTC+8 aery...@gmail.com wrote:

In the first figure, the red line is the bandwidth measurement result given by BBR. The blue line is the corresponding suggested encoding bitrate (given by the adaptive encoding module). The green histogram-like lines are the actual outbound bandwidth. The horizontal dotted line is the ground truth bandwidth.

The second and the third figure represent the corresponding RTT and pacing queue size. They together determine the lag between server and client.

By the way, I start the server and client on the same machine, only applying a bandwidth constraint to both applications using a third-party tool. So the RTprop is actually small. Does this scenario not being a "long fat network" influence the performance?

在2021年2月23日星期二 UTC+8 下午2:17:39<Aerys Nan> 写道：

在2021年2月23日星期二 UTC+8 下午2:14:50<Aerys Nan> 写道：

Hello,

Recently I am studying different congestion control algorithms of video streaming applications. I noticed that WebRTC has implemented GCC, BBR, and PCC for congestion control. However, BBR was deprecated due to some "performance issues" and removed from the codebase. I tried to run those BBR codes and found the performance is not satisfactory.

According to the results of my experiment (see the figure enclosed), when BBR does an overestimation of bandwidth, the adaptive encoding module will increase the target bitrate for the encoder. This is very different from the bulk transfer, where an overestimation doesn't increase the total amount of data to be sent. The increased bitrate will cause congestion. When inflight data is bounded by CWND, the remaining data will be piled in the pacing queue, leading to an obvious lag between a server and a client.

But the experiment results conflict with the fact that YouTube is using QUIC-BBR right now. So I have several questions:

1. Are the same problems observed in QUIC-BBR?

2. Are there some obvious differences between WebRTC-BBR and QUIC-BBR?

3. Is there any open-source platform that has a successful implementation of BBR in video streaming? It would be much better if that platform has some corresponding tools that can directly test its performance.

Thanks a lot.

Best regards,

Nan

--
You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/5a5cad39-4711-4fe2-b743-2fb1ce567d06n%40googlegroups.com.

[Dave Taht]

In general I do not feel imposing a glitch on a videoconferencing stream every 10 seconds, as BBR would do, is a good approach. Continuous measurement is needed.

I have oft-recommended that voice and video be broken out on separate 5-tuples, which, in a FQ'd system, provides a useful 20ms or so clock to measure problems and available bandwidth, and does no harm in a fifo. 

To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CADVnQynLJ2TWk5bbR7Q1uCrmSqyP1Wnj7e-ZMrZv5r5v9nfPEw%40mail.gmail.com.

--

Podcast: https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/

Dave Täht CSO, LibreQos

[Bob McMahon]

Can somebody explain the webrtc traffic profile? Is it a frames per second (isoch in iperf 2 terms) or a periodic burst? What's the send side distribution look like for the frames or bursts, or other?

Also, what's the effective phy rate of the congested link vs the send profile or better, why is the congestion there in a way it affects? Is there a concurrent or working load element here?

Bob

To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CAA93jw5ahdNBb29nT9gH0P3xD-5QX47NPv76Vrk5Au0LL5qOTw%40mail.gmail.com.

This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

[Scott Leibrand]

How are you assessing that BBR would glitch videoconferencing streams? Are you talking about a stream using TCP w/BBR instead of UDP? Or that BBR on bulk flows would somehow affect UDP streams more negatively than bulk flows using loss-based congestion control would?

Scott

On Jul 13, 2023, at 8:37 AM, Dave Taht <dave...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CAA93jw5ahdNBb29nT9gH0P3xD-5QX47NPv76Vrk5Au0LL5qOTw%40mail.gmail.com.

[Bob McMahon]

One could use iperf2 and isochronous with clock sync (UDP or TCP, though UDP is most common) to tell if a video feed glitched (which is different from DASH "glitches.") I'm doubtful that was done though to substantiate such a claim.

--isochronous[=fps:mean,stdev]

send isochronous traffic with frequency frames per second and load defined by mean and standard deviation using a log normal distribution, defaults to 60:20m,0. (Note: Here the suffixes indicate bytes/sec or bits/sec per use of uppercase or lowercase, respectively. Also the p suffix is supported to set the burst size in packets, e.g. isochronous=2:25p will send two 25 packet bursts every second, or one 25 packet burst every 0.5 seconds.)

To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/C37D5010-BF7A-4B6F-A351-07B07665C44D%40gmail.com.