Should we add a DELAY_ACK frame?

[ianswett]

As a natural opposite to #34 adding an IMMEDIATE_ACK frame, I want to know if the WG thinks there's sufficient interest in this. I know there are use cases like WebRTC where fine control over the ACKs is desirable.

@nibanks may be interested in this, since a similar topic came up on quicwg/datagram#42

[nibanks]

I would be fine with using this mechanism to solve the issues described in quicwg/datagram#42.

[mjoras]

I think this would be very useful to have. Specifically we have seen interest similar to what @nibanks has mentioned -- existing applications that have their own "application layer" (partial) reliability and congestion control but want to leverage QUIC as a connection-oriented way to send encrypted datagrams. Having more explicit control over not-ACKing would certainly help some of these usecases.

While I would rather people design protocols around QUIC application data semantics in full (streams and DATAGRAMs and some as-yet-undesigned partial reliability feature) rather than just plumbing an existing protocol over QUIC DATAGRAMs, I think that having a facility to get more applications running over QUIC is very useful.

[huitema]

Just say NO! Really, this kind of experiment goes in the way of progressing the delayed ACK proper. We have tons of experience with delayed acks, and we understand exactly what it does. Why would we create this additional mechanism, with unproven effects?

[gorryfair]

So, I think this naturally leads to the question of how long an ACK delay is actually acceptable for coexistence with other Internet use. Delayed ACKs our tens of packets are likely OK. I'll argue that "infinite" delay (No ACK) it is not a great place to dig into. I suggest we should instead be restricting this to a few RTTs... (10's? 100s of packets). I'd argue that for some form of reactive congestion control, feedback at least every few RTTs is necessary - this could even be a form of slower-reacting circuit-breaker, with the upper layers formally providing the responsive control to incipient ingestion.

[nibanks]

I'm in agreement with @mjoras that a change like this would better be aligned with the application data semantics, unreliable datagrams in this case. As I indicated in quicwg/datagram#42 (comment), there are several reasons an application protocol would want a reduction in (not complete elimination of) generated ACKs when using unreliable datagrams. There might be additional uses, generally, for delaying ACKs, but the reasoning around it is more complicated for reliable data. For the unreliable support, I can write that up in a new extension draft (if that is the general WG consensus).

[ianswett]

The idea of this extending the ACK timeout, but not removing it completely is interesting.

An alternative design would be a DELAY_ACK frame which ensured a packet doesn't elicit an immediate ACK, but would still arm the timer for the delayed ACK alarm.

[LPardue]

Given the swathe of needs and possible options, I currently think there's going to need to be some more exploration of this space with some more substantial write ups.

[ianswett]

Just say NO! Really, this kind of experiment goes in the way of progressing the delayed ACK proper. We have tons of experience with delayed acks, and we understand exactly what it does. Why would we create this additional mechanism, with unproven effects?

We already have this ACK issue with PADDING only packets, which count towards bytes in flight, but are not ack-eliciting. That design choice always terrified me. I would have been much more comfortable with something like the DELAY_ACK design I proposed just above, which would ensure you eventually get an ACK for in-flight packets.

[janaiyengar]

As a mechanism, we should not use a frame to signal how a different frame should be interpreted. QUIC's design generally assumes that a sender does not control how frames are packetized, and this runs afoul of that unstated assumption.

Specifying the mechanism is easy, but I don't think this is quite as straightforward to reason about, at least in the context of the ack frequency draft. Broadly, this is not about controlling ack frequency, it's about disabling acks, or partially disabling acks, which makes it harder to reason about.

Let's not do this here; as @LPardue notes, this has to become a larger conversation.

[ianswett]

Given the pushback against my initial attempt, I'm pivoting to the DELAY_ACK frame.

I'd actually like the negotiation of this extension to indicate the delayed ack behavior applies to PADDING only and PADDING+ACK packets as well, since I think those can be a bit of a footgun, but I'd like to see what people think of the DELAY_ACK frame before writing that text.

[kazuho]

@janaiyengar

As a mechanism, we should not use a frame to signal how a different frame should be interpreted. QUIC's design generally assumes that a sender does not control how frames are packetized, and this runs afoul of that unstated assumption.

I'm not sure if I agree. Yes, I agree with the statement that a frame should not affect how other frames are interpreted.

But we can think of DELAY_ACK frame as a frame that affects how a packet is processed. Assuming that we adopt IMMEDIATE_ACK, we'd have a precedent for having such a thing. Essentially, IMMEDIATE_ACK is a flag of a packet that happens to be sent as a frame. If we think that way, defining a DELAY_ACK frame (or a THIS_PACKET_IS_NOT_ACK_ELICITING frame) as makes perfect sense IMO.

[huitema]

@ianswett I really think this belongs in a separate draft, and mostly a separate negotiation. It should be possible to negotiate delayed acks without also negotiating ack suppression.

[ianswett]

Thanks, I've been convinced this belongs in a separate draft, and that there may be more that goes into that draft to enable the various related use cases.

I'll leave this open for now, but likely close it and the PR in the not so distant future.

[ianswett]

Closing with no action, I think this is the wrong draft.