Re: [aqm] ACK Suppression

From: aqm <aqm-bounces@ietf.org<mailto:aqm-bounces@ietf.org>> on behalf of Jana Iyengar <jri@google.com<mailto:jri@google.com>>
Date: Wednesday, October 7, 2015 at 4:56 PM
To: Christian Huitema <huitema@microsoft.com<mailto:huitema@microsoft.com>>
Cc: "dpreed@reed.com<mailto:dpreed@reed.com>" <dpreed@reed.com<mailto:dpreed@reed.com>>, "aqm@ietf.org<mailto:aqm@ietf.org>" <aqm@ietf.org<mailto:aqm@ietf.org>>
Subject: Re: [aqm] ACK Suppression

I'll be quick: we haven't actively looked at ack loss as an issue, since QUIC's mechanisms are largely independent of ack loss. It is entirely possible that we're building up a queue at the uplink, but this really shouldn't be a big issue in the common case.

That said, we'd like to solve for reducing ack packets in QUIC, and we are working on it as an e2e problem since reducing signaling redundancy seems like a sensible thing to do. Fortunately for us, middleboxes have no idea (yet) of what QUIC ack packets look like since they are encrypted, so we should be able to clearly measure issues/benefits with and without ack-decimation.

But, unfortunately for you, middleboxes have no idea (yet) of what QUIC ack packets look like, so they can't prioritize them.   Because of bufferbloat, downstream TCP throughput would really suffer if upstream ACKs got stuck at the tail of a 3000 millisecond upstream queue.  This won't be a problem for QUIC in the future when AQM is deployed, but on existing cable equipment you should expect to see the full effects of upstream bufferbloat (whereas TCP won't).

We definitely see in-network ack-decimation happening for TCP.

On Wed, Oct 7, 2015 at 2:12 PM, Christian Huitema <huitema@microsoft.com<mailto:huitema@microsoft.com>> wrote:
On Wednesday, October 7, 2015 2:00 PM, dpreed@reed.com<mailto:dpreed@reed.com> wrote:

> That's the real engineering challenge.  Modularity is your friend when engineering
> large systems with very broad requirements.  Focusing on a very narrow issue, especially
> one that assumes way too much about what should be allowed and what traffic "must"
> look like, misses the point.

This ACK thinning "optimization" obviously does not work with encrypted transports like QUIC. The network may see that some packets are short and some are long, but it cannot tell whether the short
Packets are ACK or some other management data. Quite often, they will be both.

According to our friends at Google, a fairly large part of the traffic from and to the Chrome browser now uses QUIC. If the uplink in DOCSIS networks is so limited that it would not work without ACK thinning, that would be a problem for QUIC -- and very much an illustration of Dave's "real engineering challenge." I wonder whether QUIC telemetry shows specific issues caused by congestions of the DOCSIS uplinks.

-- Christian Huitema

_______________________________________________
aqm mailing list
aqm@ietf.org<mailto:aqm@ietf.org>
https://www.ietf.org/mailman/listinfo/aqm