4 ms·
for one, not having hardware acceleration makes quic very slow compared to TCP. This is especially a problem on firewalls, as they need to tear apart and reasse
by kazen44 7y ago
for one, not having hardware acceleration makes quic very slow compared to TCP. This is especially a problem on firewalls, as they need to tear apart and reassemble tcp packets at line speed.
In terms of BGP and quic as a transport.
As far as i know, quic is not backwards compatible with TCP, and having two different transport protocols for the routing protocols that ties the internet together would be problematic in terms of migration.
Im not entirely up to speed in terms of how quick would handle MSS size, but this could pose a problem in some situations.
- fart_ratty 7y agoBGP not having security has caused many problems.
- CameronNemo 7y agoBGP has some security. It's called rpki and the industry is slowly adopting it.
- allarm 7y agoBGP over some new fancy transport protocol will cause way more problems.
- CameronNemo 7y agoPractically? Yes it will cause all kinds of chaos. Theoretically? Depends on the transport and it's characteristics. There could be a theoretical gain to using something else.
- CameronNemo 7y agoI imagine it would be fairly simple to teach a BGP implementation to use either TCP or QUIC, configurable per-session. Firewalls that dig deep into tcp packets sound like troublesome middleware with which good actors are in an arms, not something to go out of the way to support. I'll have to look into potential MSS issues.