Exposing when a datagram is acked is a footgun

[pthatcherg]

Now that we've added datagram support, Victor had a good point: an app can't rely on it. It's possible, for example, for a packet to be acked, but then dropped by the receiving browser because the JS can't keep up. Then you think it's acked, but it's not been processed. So you have to do app-level acking/feedback anyway and shouldn't trust the ack info.

They had a similar issue with HTTP3's QPACK which couldn't rely on QUIC ACKs (for streams) because there was a timing issue between the sender thinking something had been received an when the receiving application actually processed it.

Is there a scenario in which the ack info is useful and isn't a foot gun in this way?

[aboba]

Acknowledgements are used for multiple purposes, including congestion control as well as loss recovery (e.g. concealment, retransmission, determination of FEC parameters, etc.). However, I don't believe that any of these uses requires surfacing ACK information to the application:

1. As Victor noted, application-layer acknowledgement is required anyway, so even if QUIC has ACK'd, the application may still need to do loss recovery.

2. If bandwidth estimation and congestion control is handled in QUIC rather than in the application, the application doesn't require QUIC ACK info to be surfaced to it for those purposes.

[shampson]

Related to this issue - What about exposing when a datagram is considered to be lost?

The API could indicate that the packet was never lost, but then it gets dropped on the remote endpoint. I can see how this is useful for retransmitting datagrams, but would a developer have to write an application-level "lost" datagram anyways because of this issue?

[shampson]

As discussed we will remove exposing lost in the returned promise as well. Can add this as a stat.

[Atrius]

It could be quite useful to have this information if the application is involved in congestion control for datagrams, as discussed in #21.

And real-time applications might find it useful to have a finer-grained understanding of network state, even if congestion control remains in the transport. Application-layer rate control (such as adjusting encoder bitrates) might want to be more sensitive to latency than the underlying congestion controller.

[pthatcherg]

Since this appears to be gone and also only useful for congestion control, let's close this issue and move discussion to #21