[deleted]

Comments

• chonkyninja@lemmy.world ⁨19⁩ ⁨hours⁩ ago

  Random guy on internet has opinion. So what?

  source

  • fubarx@lemmy.world ⁨19⁩ ⁨hours⁩ ago

    Image

    source
• reisub@discuss.tchncs.de ⁨19⁩ ⁨hours⁩ ago

  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

  • PhilipTheBucket@piefed.social ⁨19⁩ ⁨hours⁩ 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 ⁨19⁩ ⁨hours⁩ 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

      • -> View More Comments