How to select BBR as the congestion control in QUIC code?

[chris yoyo]

Hi,

I would like to do some tests with QUIC and BBR and wanted to know how I can select BBR as the congestion control? Is there a flag which client and server can use? or should I change this in the source code and then rebuild the client and server? Also, does this have to be done on both ends, or each end can select a congestion control independent of the other end?

Thanks

[Nabil Rahiman]

ninja -C out/Default quic_server quic_client 

diff --git a/net/quic/core/quic_connection.cc b/net/quic/core/quic_connection.cc

index dadba8c..41a411e 100644

--- a/net/quic/core/quic_connection.cc

+++ b/net/quic/core/quic_connection.cc

@@ -269,7 +269,8 @@ QuicConnection::QuicConnection(QuicConnectionId connection_id,

                                                      kDefaultPathId,

                                                      clock_,

                                                      &stats_,

-                                                     kCubic, 

+                                                     //kCubic,

+                                                     kVerus,  <<< MY own congestion type, you can select your own.

                                                      kNack,

                                                      /*delegate=*/nullptr)),

       version_negotiation_state_(START_NEGOTIATION),

[Ian Swett]

If the client sends the TBBR connection option, the server will use BBR without a rebuild.  In order to change the client's congestion control to BBR, you need to add TBBR to the client_connection_options, which are part of the local config.  This approach is how we have been experimenting with BBR in Chrome.

However, for local testing, it may be easier to rebuild both binaries as Nabil mentions above.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[张晗]

Hi,

Before I rebuild the source code of quic-client, should I update the linux kernal to get the TCP-bbr?

在 2017年1月13日星期五 UTC+8下午11:39:12，Ian Swett写道：

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.

[Ian Swett]

QUIC's BBR implementation is in userspace, but you should update the kernel if you're attempting to compare it to TCP's BBR.

I will note that TCP BBR is more mature than QUIC's at this point, so I would not be surprised if it performed better.

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.

[张晗]

Thank you for your reply. You really help me a lot!

在 2017年1月19日星期四 UTC+8下午11:57:40，Ian Swett写道：

[张晗]

I just add TBBR in proto-quic/src/net/quic/core/quic_connection.cc like this:

sent_packet_manager_(new QuicSentPacketManager(perspective,

                                                     kDefaultPathId,

                                                     clock_,

                                                     &stats_,

                                                     kCubic,

    TBBR,

                                                     kNack,

                                                     /*delegate=*/nullptr)),

I rebuild the client and server by using "ninja -C out/Default quic_server quic_client",but it doesn't work. What should I do?

在 2017年1月19日星期四 UTC+8下午11:57:40，Ian Swett写道：

QUIC's BBR implementation is in userspace, but you should update the kernel if you're attempting to compare it to TCP's BBR.

[Ian Swett]

It looks like you have one too many arguments there, and need to only list kBBR, not kCubic.  TBBR is the connection option, not the enum value to pass into the QuicSentPacketManager.

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.

[张晗]

Thank you for you help! I successfully rebuild the quic_server and quic_client with TBBR.

 When I try to use local quic_client to connect quic_server, I meet follow error.

[0217/174857:FATAL:send_algorithm_interface.cc(47)] BbrTcpSender is not supported.

#0 0x000000544f6e base::debug::StackTrace::StackTrace()

#1 0x0000004309af logging::LogMessage::~LogMessage()

#2 0x000000a783ff net::SendAlgorithmInterface::Create()

#3 0x000000956c0a net::QuicSentPacketManager::SetSendAlgorithm()

#4 0x000000956baf net::QuicSentPacketManager::QuicSentPacketManager()

#5 0x000000907178 net::QuicConnection::QuicConnection()

#6 0x0000007288cd net::QuicSimpleClient::StartConnect()

#7 0x0000007282e0 net::QuicSimpleClient::Connect()

#8 0x00000040ec20 main

#9 0x7f90725d9f45 __libc_start_main

#10 0x00000040dc15 <unknown>

I am a little confused, it seems that the current version doesn't support TBBR, what should I do? 

在 2017年2月7日星期二 UTC+8下午11:56:26，Ian Swett写道：

[Ryan Hamilton]

Is your tree up to date? You're getting an error from line 47 on send_algorithm_interface.cc. Current version of that file does not have an error on that line:

https://cs.chromium.org/chromium/src/net/quic/core/congestion_control/send_algorithm_interface.cc?q=send_algorithm_interface.cc&sq=package:chromium&dr

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.

[张晗]

Yes,I update the tree and it works! Thank you!

在 2017年2月18日星期六 UTC+8上午11:24:20，r...@chromium.org写道：

[Assis Tiago de Oliveira]

Hello everyone, everything good ? I'd like someone to help.

I am trying to build quic_client with BBR, but the file you indicated is no longer present in the /src/net/quic/core/directory. How do I do the building now?

The only thing I found related to this was the /home/usr/chromium/src/net/quic/quic_flags_list.h file.  In this file there is a flag "FLAGS_quic_reloadable_flag_quic_default_to_bbr" that supposedly does this if enabled, I made a construct after I enabled this flag by setting true, is that right?

How can I see if you are really using bbr?

// When true, defaults to BBR congestion control instead of Cubic.

QUIC_FLAG(bool, FLAGS_quic_reloadable_flag_quic_default_to_bbr, false)

Another doubt! How can I see the used version of quic_cliente and server?

Thanks

[Ryan Hamilton]

On Fri, Jan 10, 2020 at 11:18 AM Assis Tiago de Oliveira <assist...@gmail.com> wrote:

Hello everyone, everything good ? I'd like someone to help.

I am trying to build quic_client with BBR, but the file you indicated is no longer present in the /src/net/quic/core/directory. How do I do the building now?

The only thing I found related to this was the /home/usr/chromium/src/net/quic/quic_flags_list.h file.  In this file there is a flag "FLAGS_quic_reloadable_flag_quic_default_to_bbr" that supposedly does this if enabled, I made a construct after I enabled this flag by setting true, is that right?

How can I see if you are really using bbr?

// When true, defaults to BBR congestion control instead of Cubic.

QUIC_FLAG(bool, FLAGS_quic_reloadable_flag_quic_default_to_bbr, false)

Yup, that's the flag. You can see it here:

https://cs.chromium.org/chromium/src/net/third_party/quiche/src/quic/core/quic_connection.cc?q=quic_default_to_bbr&sq=package:chromium&g=0&l=210

Another doubt! How can I see the used version of quic_cliente and server?

You probably want to run with --v=1.

Cheers,

Ryan

[Assis Tiago de Oliveira]

Thank you so much for the extremely prompt response!

Have an excellent day.

Att,

Assisi

[Assis Tiago de Oliveira]

I'm just trying to make it more transparent to other users who end up having the same question ...

The steps I did were as follows:

Before building quic_client, you must edit the file /home/usr/chromium/src/net/quic/quic_flags_list.h

and change a flag

// When true, defaults to BBR congestion control instead of Cubic.

QUIC_FLAG(bool, FLAGS_quic_reloadable_flag_quic_default_to_bbr, false)

to

// When true, defaults to BBR congestion control instead of Cubic.

QUIC_FLAG(bool, FLAGS_quic_reloadable_flag_quic_default_to_bbr, true)

Then just use the ninja to complete the building.

Att,

[Kyriakos Zarifis]

Hey Assis (or Ryan),

I was trying to do the same, and after setting FLAGS_quic_reloadable_flag_quic_default_to_bbr_v2 to "true" in quic_flags_list.h and rebuilding, I'm trying to verify that BBRv2 is actually used by looking at server logs ("--v=1"), but I can't seem to find anything related -- where exactly in the logs would that show?

Thanks

[Xing adsfdsa]

Hi，everyone.

do you finished your project?

I also study this

Assis Tiago de Oliveira <assist...@gmail.com> 于2020年1月11日周六 上午3:18写道：

--

You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/db04383e-5162-4d82-9e80-279b7cf29c0d%40chromium.org.

[Computing Informative]

Hello,
I am studying QUIC and want to test QUIC with Chromium, but I am very struggling with congestion control algorithms (CCA). I want to know how can I select a congestion control (Reno) as a parameter.

I am also aware that rebuilding the source code of quic-client might be necessary, but honestly, I do not get this part. In other words, after reading all the comments related to my questions on the discussion forum, I looked at the files named send_algorithm_interface.cc and quic_sent_packet_manager.cc files.

I tried and analyzed the code with these files, but these files already contain conditional statements for each congestion control algorithm.

Specifically, the send_algorithm_interface.cc file has a switch statement with each congestion control algorithm (ex: case kBBR). In the quic_sent_packet_manager.cc file, it has conditional statements if the client requests a congestion control algorithm as an independent option. With these being said, these files already have functions or handle each congestion control algorithm if it is kBBR or kBBRv2. Then, if these files already have congestion control options, why do I need to rebuild the source code of quic-client if I want to select a congestion control algorithm I want to do??

Also, if I choose a congestion control algorithm already existing in the file, will I not have to rebuild it? 

For example, BBR is already in the send_algorithm_interface.cc file.

If someone can answer my question (how to select a congestion control algorithm to Reno), I would appreciate your time and feedback.

I appreciate your understandings.

Kind Regards,
Matthew 

[Ian Swett]

Calling SetSendAlgorithm(kRenoBytes) should change the congestion controller to Reno.

ie: https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:net/third_party/quiche/src/quiche/quic/core/quic_sent_packet_manager.cc;l=145;drc=fdfd85f836e0e59c79ed9bf6d527a2b8f7fdeb6e;bpv=1;bpt=1

On Wed, Jul 12, 2023 at 3:15 AM Computing Informative <thska...@gmail.com> wrote:

Dear all

Hello,
I am studying QUIC and want to test QUIC with Chromium, but I am very struggling with congestion control algorithms (CCA). I want to know how can I select a congestion control (Reno) as a parameter.

I am also aware that rebuilding the source code of quic-client might be necessary, but honestly, I do not get this part. In other words, after reading all the comments related to my questions on the discussion forum, I looked at the files named send_algorithm_interface.cc and quic_sent_packet_manager.cc files.

I tried and analyzed the code with these files, but these files already contain conditional statements for each congestion control algorithm.

Specifically, the send_algorithm_interface.cc file has a switch statement with each congestion control algorithm (ex: case kBBR). In the quic_sent_packet_manager.cc file, it has conditional statements if the client requests a congestion control algorithm as an independent option. With these being said, these files already have functions or handle each congestion control algorithm if it is kBBR or kBBRv2. Then, if these files already have congestion control options, why do I need to rebuild the source code of quic-client if I want to select a congestion control algorithm I want to do??

Also, if I choose a congestion control algorithm already existing in the file, will I not have to rebuild it??

For example, BBR is already in the send_algorithm_interface.cc file.

If someone can answer my question (how to select a congestion control algorithm to Reno), I would appreciate your time and feedback.
I appreciate your understandings.

Kind Regards,
Matthew 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/ddc57ce7-6362-417b-91cf-5071dd35876dn%40chromium.org.

[Computing Informative]

Dear Ian Swett

First of all, thank you for your response.

Your time and feedback helped and saved my time! 

I want you to help me with one more part. 

I have one more question.

Where do I need to call SetSendAlgorithm(kRenoBytes)? 

In other words, do I call this function (SetSendAlgorithm) from quic_connection.cc file? OR Do I call it from the send_algorithm_interface.cc file?

I am very confused with this part.

I appreciate your understandings.

Kind Regards,

Matthew 

[Computing Informative]

Dear Ian Swett

Thank you for your response.
I think I am unsure if I understood correctly, but I think I have a clue.  :) 
I have one more question to clarify something.

When you say "Calling SetSendAlgorithm(kRenoBytes)," do you mean that I need to call the function from another file?  OR 

Do you mean that I need to modify something SetSendAlgorithm(congestionControlType) to change the congestion controller algorithm (CCA) to Reno?

I appreciate your time and understandings!

Kind Regards,
Matthew

On Thursday, July 13, 2023 at 2:38:02 AM UTC+9 Ian Swett wrote:

[Computing Informative]

Dear Ian Swett

Thank you, Ian!
Solved the problem now!

At first, I was confused and did not understand it correctly but now recognized it.  :)

Sincerely,
Matthew S.

On Thursday, July 13, 2023 at 2:38:02 AM UTC+9 Ian Swett wrote: