CCA and linux reaction on demand

[Simon]

Hello,

I'm looking for some clarification on a few basic principles of bandwidth allocation.

Is BBR inherently demand-agnostic? For instance, if we had two applications/iperf sessions sharing a 10 Mbps link, one with an 8 Mbps demand and the other with 5 Mbps, would they receive roughly the same bandwidth, or would the first one get more? What about if the demands were 8 Mbps and 3 Mbps? Would the second one get 3 Mbps, and the first one whatever's left? 

Also, does it make any difference if the clients/applications are on the same or different (Linux) servers?

And what about CUBIC and tc netem? Do they take application demand into account, or do they influence resource allocation while simply ignoring it?

Lastly, would there be any noticeable difference for any of this questions if we had an unmanaged switch with a very tiny buffer size versus one with a very large buffer between the client and server?

Regards,
Simon

[Neal Cardwell]

Hi Simon,

Here are some quick takes on these questions. Of course the real answer would come from experiments, but here are some guesses:

On Fri, May 23, 2025 at 9:54 AM Simon <kasteli...@gmail.com> wrote:

Hello,

I'm looking for some clarification on a few basic principles of bandwidth allocation.

Is BBR inherently demand-agnostic?

I can't think of any congestion control algorithm that is demand-agnostic. :-) Generally, a congestion control algorithm won't be able to achieve throughput higher than what the application tries to use (unless the transport protocol or congestion control algorithm synthesizes fake data to send to soak up bandwidth).

 

For instance, if we had two applications/iperf sessions sharing a 10 Mbps link, one with an 8 Mbps demand and the other with 5 Mbps, would they receive roughly the same bandwidth, or would the first one get more?

I suspect the flows would both achieve roughly 5 Mbps (unless they have different RTTs, in which case BBR's RTT-unfairness issues would come into play).

 

What about if the demands were 8 Mbps and 3 Mbps? Would the second one get 3 Mbps, and the first one whatever's left? 

Yes, that is my guess.

 

Also, does it make any difference if the clients/applications are on the same or different (Linux) servers?

AFAICT it depends on whether the bottleneck moves to the server's NIC, and if so, what the qdisc is for transmissions from that NIC.

If the server's NIC is faster than the sum of the demands of the apps, and faster than any potential bottleneck links in the network, then the bottleneck will not move to the server, and the fact that the flows are on the same server should not matter.

If the server's NIC is the bottleneck, then the server's qdisc will come into play. Hopefully the server is using a modern qdisc like fq_codel and fq, and that will enforce fairness explicitly. Even if it's using a pure FIFO qdisc, the flows should converge to fairness via some combination of TSQ and normal BBR sharing dynamics. (Again, if one flow is using less than its fair share, then that flow will only get what it tries to use, and the other flow will get whatever is left.)

 

And what about CUBIC and tc netem? Do they take application demand into account, or do they influence resource allocation while simply ignoring it?

CUBIC traffic through any bottleneck will also implicitly take application demand into account. Like with BBR, a CUBIC flow can't achieve a throughput higher than it tries to achieve. :-)

 

Lastly, would there be any noticeable difference for any of this questions if we had an unmanaged switch with a very tiny buffer size versus one with a very large buffer between the client and server?

AFAICT, in principle the depth of the bottleneck buffer should only change the RTTs, loss rates, and time constants of convergence, not the basic properties.

best,

neal

 

Regards,
Simon

--
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 visit https://groups.google.com/d/msgid/bbr-dev/3c1ce597-4da5-4b0b-becd-33df8f208dffn%40googlegroups.com.