Subject: Current QUIC performance is compromised compared to TCP for asymmetric paths

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 20 Apr 2020 13:59:17 +0100

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

---

From: "Border, John" <[email-masked]>
Date: Mon, 20 Apr 2020 14:27:23 +0000

The current world situation has also highlighted another aspect of the asymmetric path problem.  The smaller path is not just used for ACKs.  With everyone working from home, there is a now a lot more inbound traffic on the network.  The ACK traffic is competing with that, squeezing the pipe more.  The same is true in the other direction, of course.  But, the fatter direction can handle it much better.

John

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Gorry Fairhurst
Sent: Monday, April 20, 2020 8:59 AM
To: QUIC WG <[email-masked]>
Subject: Current QUIC performance is compromised compared to TCP for asymmetric paths

**EXTERNAL EMAIL** 

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://urldefense.com/v3/__https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/__;!!Emaut56SYw!jqMqlunZTo6taRhiwlrZ_N4yygDyaEg1tV4hxzQnfttBQxLOJBscjRiNJJeNeU5TKw$ 

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

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Tue, 21 Apr 2020 07:50:22 +0000

Hi Gorry,

Thanks for sharing the slides. The difference in amount of return traffic for QUIC vs TCP on slide 6/7/8 is very interesting to note. However I didn’t understand few things: 
1. On slide 8, even under loss conditions the QUIC ACK frames are almost same (or even marginally less).
2. On slide 8, what are the percentages mentioned in parenthesis?
3. On slide 6, why the variation in ACK traffic is so high between QUIC implementations even with same 1:2 ACK ratio?

I am interested in this subject matter and we have a relevant draft [1] in TCPM.

We tried ourselves analyzing what is the max reduction in ACK traffic that can be achieved without (much) impacting the transport performance. We realized there was no one answer for this and generalizing the behavior with optimal settings is a pretty big effort.

Nevertheless, we tried to solve the problem for our use-case which was: Local Wireless Projection (specifically screen-casting i.e., projecting phone screen on the TV). It required high-throughput and UX was susceptible to latency/jitter. Speaking only in the context of ACKs, we found that an off-the-shelf TCP implementation resulted in lot of ACK traffic and didn't provide much knobs to improvise and this had impact on the overall good-put for reasons listed in the draft.

We did our experiments (tried generalizing to other use-cases) and found that it is possible to reduce much of the ACK traffic with positive impact on the good-put especially considering the wireless scenario.
However there were problems,
- with respect to min-RTT estimation (especially in high jitter conditions with 5Ghz transmission when the distance between phone and TV is increased)
- issues with window updates, loss recovery, send pattern
We provided some heuristics we used to reduce the ACK traffic in the draft. All in all, we found it is possible to alleviate the risks associated with these problems.

In our use-case we had control over the phone and the TV transport and this may be is not very common. We understand that generalizing the ACK reduction requires much bigger efforts and I, for one, would like participate in any such effort.

With respect to, setting a default of 1:10 in place of 1:2 for ACK policy imo sounds like a good first step. However, there will be implications for min-rtt calculation and others (mentioned above), especially for scenarios not involving bulk transfer. Also if 1:10 policy is used should the delayed ACK timers remain as-is, the pdf didn’t mention the delayed ACK timers that were used.

Best,
Rahul

[1] https://tools.ietf.org/html/draft-li-tcpm-advancing-ack-for-wireless-00

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: 20 April 2020 20:59
To: QUIC WG <[email-masked]>
Subject: Current QUIC performance is compromised compared to TCP for asymmetric paths

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 22 Apr 2020 08:50:57 +0100

Hi, see below:

> 1. On slide 8, even under loss conditions the QUIC ACK frames are almost same (or even marginally less).
True - we see more packets and bytes overall in case of loss, but the 
averaged number of bytes in ACK frames is sometimes similar. I think 
this depends very much on the pattern of loss. At higher loss rates I'd 
expect a much bigger consistent difference.
> 2. On slide 8, what are the percentages mentioned in parenthesis?
This is the percentage of the total volume of bytes sent on the forward 
path.
> 3. On slide 6, why the variation in ACK traffic is so high between QUIC implementations even with same 1:2 ACK ratio?
It's important to understand that this is just one implementation choice 
in each case. The implementations are evolving, The illustration shows 
that implementations can take different choices within the spec., and 
the composition of frames they choose to send. Also, to note that the 
slide includes all traffic seen on the return path, minus the initial 
crypto frames.
> - with respect to min-RTT estimation (especially in high jitter conditions with 5Ghz transmission when the distance between phone and TV is increased)
As I understand, QUIC currently uses min_RTT for CC, but as a threshold 
for rejecting bad data, so I'd not expect a significant impact of 
reduced min_RTT accuracy in QUIC.
> We provided some heuristics we used to reduce the ACK traffic in the draft. All in all, we found it is possible to alleviate the risks associated with these problems.
Again, QUIC has taken slightly different approaches which I think make 
it easier to do this than for TCP.
> With respect to, setting a default of 1:10 in place of 1:2 for ACK policy imo sounds like a good first step. However, there will be implications for min-rtt calculation and others (mentioned above)…
Finally, the default ACK delay used by Chromium and Quicly we believe is 
25ms, as per the Spec. This seemed a reasonable choice to us. Clearly 
tuning the ACK Ratio for a specific CC behaviour is also possible and 
then you'd likely wsih to change this value also - but as a default this 
seemed good.
> [1] https://tools.ietf.org/html/draft-li-tcpm-advancing-ack-for-wireless-00
Best wishes,

Gorry

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Apr 2020 20:47:57 +0300

Hi,

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

thanks, Gorry.

Folks who care about a change here should please prioritize progressing this issue. We're close to being able to last-call the specs, and would like this resolved in time.

Thanks,
Lars