Exposing when a datagram is acked is a footgun about webtransport HOT 5 CLOSED

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.

from webtransport.

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?

from webtransport.

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

from webtransport.

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.

from webtransport.

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

from webtransport.