Comment

I have some problems with this article. I mean, it’s an ok overview, but is missing some critical things that make me think the author is not that deep into congestion control research.

they do not mention Cubic, the current default algorithm for Linux, which scales a lot faster than Reno
They link to original BBR paper from 2017, while in the meantime BBRv3 has gotten some significant changes
QUIC still uses congestion control, usually in the form of BBRv… You cannot omit congestion control for QUIC, otherwise we would experience the congestion collapse all over again. QUIC must be TCP friendly after all.
Last remark: congestion control is under the control of the sender, i.e. of the server. CDNs and big service providers are constantly tuning their setups, I do not expect that they run the default settings.

source

Sort:hotnew top

PhilipTheBucket@piefed.social ⁨1⁩ ⁨day⁩ ago
Hm, I think you are right. Looking at it again, there's also this:

For one, enterprises largely disable QUIC and force websites like Google to downgrade back to TCP. This is because there’s only a single firewall vendor that can decrypt and inspect QUIC traffic (Go Fortinet!).

I definitely don't think that is how it works. Maybe enterprises disable QUIC, but it's not because they can decrypt and inspect HTTPS traffic.

source
- reisub@discuss.tchncs.de ⁨1⁩ ⁨day⁩ ago
  I think that part is correct, as in: corporations often use corporate proxies, which terminate the HTTPS connection internally and scan the content. However, I don’t know if these proxies can use QUIC for the outside connection
  
  source
  - PhilipTheBucket@piefed.social ⁨1⁩ ⁨day⁩ ago
    Oh... yeah, that makes more sense than "decrypting" it to inspect it.
    
    Anyway, I think I'll delete the article, I think you're right and it is unuseful.
    
    source