3 ms·
there's a bunch of bullet points going through some staple material, but the last bullet point has some absurdly good high grade features! > and much more, inc
by rektide 5y ago
there's a bunch of bullet points going through some staple material, but the last bullet point has some absurdly good high grade features!
> and much more, including CUBIC congestion controller support, packet pacing, Generic Segmentation Offload support, Path MTU discovery, and unique connection identifiers detached from the address
also, a blog announcement appeared for this, https://aws.amazon.com/blogs/security/introducing-s2n-quic-open-source-protocol-rust/ https://aws.amazon.com/blogs/security/introducing-s2n-quic-o...
- jeffbee 5y agoI wonder why ye olde CUBIC without offering a choice of BBR or - dare I dream it - Swift.
- electricshampo1 5y agoIs Swift (https://dl.acm.org/doi/pdf/10.1145/3387514.3406591 https://dl.acm.org/doi/pdf/10.1145/3387514.3406591) expected/designed to be used in non-intra dc environments where primarily quic is expected to have an advantage relative to tcp? I agree that it still would be nice to have as an option.
- jeffbee 5y agoWell I don’t really agree with the premise of your statement. I think that the benefit of the new protocol is going to mostly be felt inside the data center.
- Matthias247 5y agoCUBIC is a good baseline congestion controller. It's the default one that is being used in Linux, so it should provide adequate performance for a wide range of use-cases. Plus it's not so "olde" - the specification is actively improved (see https://github.com/NTAP/rfc8312bis https://github.com/NTAP/rfc8312bis), and the implementation of the algorithm inside s2n-quic even lead to the discovery of spec gaps that had been fixed as part of this effort. Like most other QUIC libraries the congestion controller is also pluggable. So if a different one makes more sense for a particular use-case, it could be integrated in the future.