BBR usage and traffic share

[X Y]

Hello,

I understand this may not be directly related to BBR development, however, I would be grateful if you could assist me with a few questions regarding BBR and Google's traffic. If there is a more appropriate channel for this, I would appreciate being directed there.

  
In our organisation my colleagues and I are conducting research on the impact of buffer size on network devices with bottlenecks on network congestion. Congestion control algorithms (CCA) also play an important role in dealing with traffic congestion, specifically BBR(vX) developed by Google. We aim to synthesize traffic closely resembling real-world traffic. Since traffic from Google represents a large share of total Internet traffic, I would like to ask for some clarification, if possible and if it does not involve overly confidential information.

For certain assumptions, I am referring to the document available at the following link: https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00

1. If I understand correctly, only version 3 of BBR (i.e., BBRv3) is used on your side for external traffic, and not v1 and v2 anymore?
2. What proportion of your entire public traffic (towards users) uses BBR? The document states that all traffic from google.com and all YouTube traffic uses it. What about other traffic (eq. Drive, Photos, ...), which CCA does it use?
3. Does QUIC at the application level also use BBRv3? Is this specific to your organization, or do all web providers using QUIC use BBR as CCA? If not, what is usually the CCA for QUIC?
4. What CCA is used if the client uses, for example, CUBIC as CCA and the server uses BBR? Or to put it another way - can the server force BBR? Because if I understand correctly, this is not possible with other CCAs? Is there any difference between TCP and QUIC regarding this?

Best Regards,

Xandy

Best Regards

[Neal Cardwell]

On Fri, Jan 17, 2025 at 8:49 AM X Y <stro...@gmail.com> wrote:

Hello,

I understand this may not be directly related to BBR development, however, I would be grateful if you could assist me with a few questions regarding BBR and Google's traffic. If there is a more appropriate channel for this, I would appreciate being directed there.

  
In our organisation my colleagues and I are conducting research on the impact of buffer size on network devices with bottlenecks on network congestion. Congestion control algorithms (CCA) also play an important role in dealing with traffic congestion, specifically BBR(vX) developed by Google. We aim to synthesize traffic closely resembling real-world traffic. Since traffic from Google represents a large share of total Internet traffic, I would like to ask for some clarification, if possible and if it does not involve overly confidential information.

For certain assumptions, I am referring to the document available at the following link: https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00

1. If I understand correctly, only version 3 of BBR (i.e., BBRv3) is used on your side for external traffic, and not v1 and v2 anymore?

Hmm, there is a typo in that slide. Only TCP traffic from Google/YouTube services is using BBRv3. Most QUIC traffic from Google/YouTube services is still using BBRv1; there is work under way to transition Google/YouTube QUIC to BBRv3, but currently this is at a stage with some small scale experiments comparing BBRv3 with BBRv1.

 

2. What proportion of your entire public traffic (towards users) uses BBR? The document states that all traffic from google.com and all YouTube traffic uses it. What about other traffic (eq. Drive, Photos, ...), which CCA does it use?

100% of Google's public TCP/QUIC traffic uses some version of BBR. The "google.com" qualifier is meant to apply to Google services like Drive and Photos and Gmail (note that they use domains that end in google.com, like drive.google.com, photos.google.com, mail.google.com, etc).

 

3. Does QUIC at the application level also use BBRv3? Is this specific to your organization, or do all web providers using QUIC use BBR as CCA? If not, what is usually the CCA for QUIC?

Every QUIC library has its own default CCA and set of available CCAs. AFAIK usually CUBIC is the default, though AFAIK some offer Reno or BBR implementations.

This paper may be of interest (see "Table 1: List of QUIC/TCP stacks studied and their available CCAs."):

  Containing the Cambrian Explosion in QUIC Congestion Control
  https://dl.acm.org/doi/10.1145/3618257.3624811

 

4. What CCA is used if the client uses, for example, CUBIC as CCA and the server uses BBR?

TCP and QUIC use sender-based CCAs, so each data sender decides what CCA it will use, and applies that. If the client uses CUBIC as CCA and the server uses BBR, then the rate of data from the client will be decided by the client's CUBIC instance, and the rate of data from the server will be decided by the server's BBR instance.

 

Or to put it another way - can the server force BBR? Because if I understand correctly, this is not possible with other CCAs?

It is generally not possible for a TCP or QUIC endpoint to explicitly force the remote side to use a particular congestion control algorithm. However, an endpoint can use mechanisms like advertised receive windows to request a reduction in the sending rate of the remote peer, implicitly causing the remote peer to send slower in a way that indirectly amounts to a new CCA (see, for example, RLEDBAT: https://datatracker.ietf.org/doc/draft-irtf-iccrg-rledbat/ ).

 

Is there any difference between TCP and QUIC regarding this?

TCP and QUIC are the same in this regard.

best,

neal

 

Best Regards,

Xandy

Best Regards

--
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/115150e5-4f32-4388-8113-9349c3eb5b48n%40googlegroups.com.

[X Y]

Thank you very much, it clarifies a lot for our work.