I tend to call people out when they make claims that are not accurate.
> I care about what people _do_, not what they say in their PR blogs.
Did you read the blog? It's not just words, they are talking about products they have shipped. E.g. Files Go. You can believe what you want, but if you're going to big claims, you should back those up with credible data.
Further, we found that QUIC consumes significantly more than its fair share of bottleneck bandwidth when competing with TCP flows, which can be detrimental to a wide range of applications.
QUIC is at its essence an ARQ protocol, i.e. feedbacks are required to recover from packet losses. And this design choice then leads to inefficiencies when evaluating link conditions. And, in links where latency and losses are unstable, these limitations lead to a significant performance loss.
if you're going to big claims, you should back those up with credible data.
It does show QUIC falling apart with _out of order delivery_, however that is not something that latency or slow networks will produce. There is no reason to think that slow / third world countries have significantly more out of order delivery. The networks might be slower / have higher latencies, but packet order is likely to be the same.
That is different than dropped packets requiring retransmissions, but given QUIC and TCP both use the same congestion control algorithm (Cubic) there should be no difference on that score.
In terms of it being “unfair” when both types of streams are present that’s correct, but TCP with BBR also produces this kind of effect. It’s the algorithm used, not whether it’s QUIC or TCP, that causes this.
QUIC is not perfect, it’s still only at draft stage in the IETF. I’d be concerned that arguments like this are being made which, while seemingly well intentioned, have the effect of stifling innovation for all internet users.
You can bet that on a high latency link the fewer round-trips to set up a TLS connection with QUIC are gonna improve things.
The claim I was referencing was taking a weakness in protocol, and jumping to conclusions.
This would be the equivalent of one saying, "You don't care about the environment because you took a gas powered bus today". And then provide evidence about how busses are harmful to the environment, and provide details about busses emitting GHGs.
Likewise, you can't jump from a weakness in QUIC to big tech doesn't care about NBU.. when in reality, much of big tech pours so much engineering effort towards NBU (amongst other things). Files Go is a small example, and you can download the app here: https://play.google.com/store/apps/details?id=com.google.and.... It is not vaporware.
I would love to see the evidence for this as well.
Instead of providing any you just attacked the person who questioned you?
What specifically about the transport layer in QUIC makes it perform poorly on high latency links? It’s going through the IETF now I’d be surprised if they were complicit in such a backwards move.
Do you have a citation for your claims? There is plenty of evidence to the contrary: https://www.blog.google/technology/next-billion-users/ .