Soliciting ACKs

[martinthomson]

We now forbid the generation of an ACK in response to an ACK (lest the two endpoints talk each other to death over nothing), rather than recommend acknowledging only a fraction of ACKs. That's great, and much easier to implement.

However, when removing STOP_WAITING, @ianswett wanted to have a way to solicit an ACK so that a receiver could stop sending acknowledgments for some packets. He suggested using PING, which is great. I have another suggestion that I think is superior: WINDOW_UPDATE. Like PING, WINDOW_UPDATE causes an ACK to be generated, albeit with less urgency and a receiver is highly like to need to send one occasionally. I think that PING is still viable, but WINDOW_UPDATE is likely to happen naturally anyway.

[marten-seemann]

Interesting idea. One (important?) difference is that a WINDOW_UPDATE is retransmittable.

[ianswett]

Great idea, let's change it to recommend WINDOW_UPDATE. It is natural to bundle flow control updates with acks and when autotuning is implemented well, one would send a flow control update message slightly less than once per RTT when not application limited.

PING is also retransmittable, so that doesn't change.

[janaiyengar]

It does depend on exactly how often the receiver may want to send a WINDOW_UPDATE (Chrome advertizes a 10MB offset, so UPDATEs are not really frequent.) I'd say that an implementation can make this decision on its own... if you're about to or just did send a STREAM frame, you don't need to send anything. I would generalize this recommendation to say something like "when an endpoint needs to solicit an ACK, it sends a retransmittable frame. A PING frame is a natural choice, but a WINDOW_UPDATE may be used as well, if the endpoint expects to send one anway. The endpoint may already be waiting for an ack of a STREAM_FRAME, and may therefore not need to send any additional frames."

[ianswett]

I would slightly prefer recommending the receiver send a WINDOW_UPDATE instead of a PING, since it's actually a useful frame. And I'd rather have a specific recommendation, than leave it open to implementers.

I plan to implement this soon in GQUIC, and I'd definitely prefer sending a WINDOW_UPDATE instead of a PING.

[martinthomson]

Yeah, not sure if the fact that you are encouraged to repair WINDOW_UPDATE is a feature, bug, or just an irrelevant bit of info. Not getting an ACK for that packet means that you might have to send again, but the same is more or less true for PING too (given that the usual reason to send PING is to solicit an ACK).

[ianswett]

Yeah, well the term retransmittable is used, but it really comes down to whether a peer is expected to ack the packet.

In QUIC, there's never a contract anything needs to be retransmitted as is, to my knowledge. In the case of WINDOW_UPDATE, it'd make a lot more sense to send an updated WINDOW_UPDATE if the first is lost than retransmit the same one again. But I do think it's important to know if the WINDOW_UPDATE arrived, and for now, that means considering it retransmittable.

[janaiyengar]

I don't think sending a WINDOW_UPDATE is a problem. If you have a choice between WINDOW_UPDATE and PING, sure, send WINDOW_UPDATE.

OTOH, there's no reason to send anything if you've just sent either a PING or another "retransmittable" frame, where retransmittable means that the sender is expecting to receive an ACK. It's silly to send a frame to evoke an ACK if you've just sent one that will do exactly that, so a sender could optimize here, as long as this the text here doesn't limit ACK solicitation to a WINDOW_UPDATE.