[eadan]

How well does QUIC perform over networks with relatively high packet loss? It seems like Aspera (https://www.ibm.com/products/aspera) is the industry standard for high performance WAN transfers, but it's a proprietary protocol. I'm wondering if QUIC performs better than HTTP1/2 in this respect?

[bawolff]

That is the use case its targeting (relative to http/2)

[fulafel]

The drafts don't seem to mention that this use case would be at the forefront or better than with HTTP/2, got any pointers?

Generally high loss is not well tolerated by internet protocols, so high loss networking technologies tend to handle forward error correction and retransmissions in protocol layers below IP.

[atesti]

How does Aspera work?

How is it possible to be 1000x faster? Is it?

TCP works by slowing the data rate when data loss happens. On purpose, to be fair!

I think it's not that hard to write a program/protocl that blasts out a big file over UDP and just sends all the parts as packets, then waits for the receiver to assemble a big list of missing packets, send them back and have the sender blast out everything again at a high rate.

But this would be at the expense of all the other TCP connections.

Wasn't QUIC changed to be so called "TCP friendly", that means that it has the same back off behaviour as TCP so that if you are in a crowded hot spot every tcp stream has a fair chance?

(On the other site, google and some other companies have a huge initial TCP window size and try (or tried?) to send e.g. the whole google homepage with like 8 1500 byte packets at once, also trying to get a better ux than other, again on the expense of other TCP streams)

Looks like using Aspera is unfair and only works if a few people do it.

[eadan]

My understanding is that the protocol underlying Aspera (FASP) uses UDP for the main data transfer and a TCP connection for coordination. By using UDP for data transfer it's not restricted to the ACK ranges imposed by TCP which can hinder throughput on networks with relatively high packet loss. Its throughput is not necessarily achieved by being a "bad citizen" but by having full control over how and when it communicates lost packets.

Since QUIC is also over UDP, perhaps we now have more flexibility on ACK windows etc.

Btw. there are open protocols like Tsunami UDP (https://en.wikipedia.org/wiki/Tsunami_UDP_Protocol) that try to fill the same niche

[the8472]

My understanding is that window scaling and SACKs enable TCP to detect losses within large segments too. The only limitation is that most congestion controllers throttle back when detecting packet loss. Newer latency-based controllers don't suffer from that problem.

[eadan]

This is interesting. I haven't seen much in regard to comparing TCP+BBR to FASP other than a masters thesis which suggests FASP outperforms on transferring large files over long distances (which is exactly its intended purpose). But, I wonder if splitting a file over multiple QUIC connections and re-assembling at the other side would come closer to the performance of FASP? Could be a fun experiment, I might try it!

[the8472]

An optimal CC should have high utilization with a single stream¹ and behave fairly to other connections on the network. Measuring multiple streams misses the point of the exercise.

> other than a masters thesis which suggests FASP outperforms on transferring large files over long distances

I found that one too. I would take it with a grain of salt since it uses scp for data transfer (which has its own flow control and may be the limiting factor here) and doesn't list the values of some important tcp settings, e.g. tcp_wmem, which can be essential for transoceanic connections.

¹ ignoring the case where a single CPU core can't move bytes fast enough to saturate a link.

[the8472]

They are probably comparing their product to classic TCP congestion controllers running on long fat pipes with high packet loss. If you swap in BBR that advantage will probably shrink or vanish.