Receiver buffer size

[Arash Molavi]

Hi,

I have a couple questions regarding the receiver buffer size. In Chromium's stable channel (52.0.2743.116), the quic_server uses a buffer size of 256*1024 (kDefaultSocketReceiveBuffer), which results in maximum congestion window and slow start threshold of 107 packets (configured when creating the SendAlgorithmInterface). When I connect to quic_server with Chrome, the client sends SRBF = 1048576 (=1024*1024). The server updates the maximum congestion window (to 430 packets) upon receiving this new buffer size, but it does not update the slow start threshold. Is there a reason for this? When there is ample bandwidth available, having such a small slow start threshold compare to the max congestion window causes QUIC to take a long time to ramp up to maximum available bandwidth.

Are you able to discuss what is the default buffer size that Google servers' use? Doing some tests against app engine, it seems like it is configured to use receiver buffer size of 1024*1024 to set the max win size and SS threshold. Is this correct? (I can see that the dev channel uses this number)

I also appreciate any clarification on how this buffer size (and the 0.6 conservative fraction) is picked.

Thank you!

[Ian Swett]

Originally the receive buffer value was an effort to communicate what the peer's socket receive buffer value.  What this actually did was limit the congestion window to the receiver's receive buffer size, multiplied by a 'fudge factor'.  This turned out to add complexity without really being that useful.  The 0.6 value was arrived at because it turns out Linux has some overhead, so if you set a receive buffer size of 1MB, you can only consistently store about 0.6MB of data.

This code is now obsolete, and Google(as with the Chrome code) defaults to a max CWND of 2000 packets.

https://cs.chromium.org/chromium/src/net/quic/core/congestion_control/send_algorithm_interface.h?l=26

Thanks for noting about slow start.  I can imagine that being a bug in the old code, but the new code that always uses 2000 as a max shouldn't have that bug, see: https://cs.chromium.org/chromium/src/net/quic/core/congestion_control/send_algorithm_interface.cc?l=23

Please tell me if I'm wrong about the bug still being present.

--
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.

[Arash Molavi]

Awesome. Thank you Ian, this is great information. I will definitely let you know if the bug was still present.

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