The primary tradeoff of initcwnd is setting a reasonable window before you've learned anything about the path. BBR has little say on this because it takes, in relative terms, quite a while to go through its phases. An early BBR session is therefore not really superior to other congestion controls because that is not the problem it is really focused on.
Jacking up the initcwnd, you start to risk tail loss, which is the worst kind of loss for a sliding window.. especially in the primordial connection. There are ways of trying to deal with all that but they are loss predictions.
If you are a big enough operator, maybe you have some a priori knowledge to jack this up for certain situations. But people are also reckless and do not understand the tradeoffs or overall fairness that the transport community tries to achieve.
As other comments have pointed out, QUIC stacks also replicate congestion control and other algorithms based on the TCP RFCs. These are usually much simpler and lacking features compared to the mainline Linux TCP stack. It's not a free lunch and doesn't obviate the problem space any transport protocol has to make tradeoffs on.
Having to pick a particular initcwnd to be used for every new TCP connection is an architectural limitation. If they could collect data about each destination and start each TCP connection with a congestion window based on the recent history of transfers from any of their servers to that destination, it could be much better.
It's not a trivial problem to collect bandwidth and buffer size estimates and provide them to every server without delaying the connection, but it would be fun to build such a system.
Also he raised a bunch of funds to dig one up under the ocean and got nothing.
I’m inclined to let those searchers speculate in public. If society’s rule is that you can’t even speculate about X until you have proof, it will hold back science significantly. History has many such examples of forbidden speculation leading to long delays.
> The tragedy of the commons is the concept that, if many people enjoy unfettered access to a finite, valuable resource, such as a pasture, they will tend to overuse it and may end up destroying its value altogether. Even if some users exercised voluntary restraint, the other users would merely replace them, the predictable result being a "tragedy" for all.
There is no right of absolute freedom, because at some point that freedom affects other people who also have rights. So we're always limited explicitly and implicitly in what we can do. Free, unfettered access just means taking something away from somebody else.
We used to have to leave a lot of space between satellites because their orbits varied unpredictably, but we've gotten better at packing them.
Someday we'll talk about the days of 5000 satellites like we talk about when computers had 4096 bytes of RAM, and it will be fine.
#include <emscripten.h>
void sayHello()
{
EM_ASM(
let foo = document.getElementById('foo')
foo.innerHTML = 'hello';
);
}
See https://emscripten.org/docs/porting/connecting_cpp_and_javas...Before WASM, the options were:
- require everyone to install an app to see visualizations
- just show canned videos of visualizations
- write and maintain a parallel Javascript version
Demo at https://throbol.com/sheet/examples/humanoid_walking.tb
How have they advertised that? Was it clock frequency? Their mitigations mean it still runs at that clock frequency.