Current QUIC performance is compromised compared to TCP for asymmetric paths

[Gorry Fairhurst <[e-mail]>]

We had prepared some slides for the Vancouver IETD to discuss QUIC's 
ACKs, and how to make QUIC work better than TCP in common asymmetric paths.

This is a short slide deck that summarises what we have learned about 
ACKs in QUIC:

https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/

It compares the ACK traffic of TCP with that of QUIC from the point of 
view of a path where QUIC's return traffic is somehow constrained or 
could impact other user traffic. We think that ACKs are a concern for 
various shared capacity return link (e.g., radio-based methods in WiFi 
or mobile cellular were ACKs consume spectrum/radio resource or battery; 
shared capacity satellite broadband return link or the uplink of a cable 
system). For TCP, such systems commonly involve a PEP or an ACK 
Filtering mechanism (which clearly isn't wanted or even possible for 
QUIC). The baseline QUIC performance (as per current spec) suffers over 
these paths.

So our first question is: Do other people think it is important that the 
default specified for QUIC works well with  asymmetric paths ?

Gorry