Congestion related information to the application about datagram HOT 8 CLOSED

Section 5.2 indicates that QUIC may notify the application when the datagram is ACKed, and Section 5.4 says QUIC may notify the application when the datagram cannot be sent due to congestion control.

As far as I can see, those are the only concrete notifications that are appropriate that are specific to the DATAGRAM frame.

I can absolutely see how a media streaming application may want to get other notifications about loss detection and ECN in general, but those seem to be generic features of QUIC notifying the application, and are not specific to this particular frame type. As such, I feel that this belongs in other future documents.

from datagram.

Congestion control state is a property of the connection, not isolated to this extension or of a particular use of this extension. It seems fine to me to let implementations figure out what is sufficient information to applications. If there's something common worth detailing more, that can be documented elsewhere.

from datagram.

+1 to what @tfpauly said. We've built a real-time media application over QUIC DATAGRAMs at Google, relying only on a notification when a datagram is ACKed or considered lost. Implementations are free to share more information with the application, but we shouldn't recommend an unimplemented technique that might not even work.

from datagram.

I have some experience with SCReAM, where it is definitely necessary to notify the application level about congestion.. The result is otherwise that a queue will build up on the sender side.
This is perhaps not an issue if the delay budget for the application is measured in seconds, but if the goal is low latency streaming, then I would say that it is necessary.
If one try and distill the bare necessities out of SCReAM then one can implement something that signals the necessary target bitrate reduction up to the application (video encoder).
This signal is transmitted upon each new congestion event and is simply a metric that indicates the expected fractional decrease of the output rate by the QUIC connection. This is given by how much the congestion window decreases and the expected reduction in RTT. This is a relatively exact metric with L4S as the RTT is essentially unchanged. With loss based and ECN it becomes more of an approximation.

from datagram.

@DavidSchinazi , then you have experience of real-time application over QUIC DATAGRAM. if I understand it correctly, you needed the DATAGRAM ACK information, right?

@tfpauly I can agree that those two notifications are the relevant to DATAGRAM frames. However, from our work on RMCAT working group, I am concerned that application developers will need more information for a proper rate controlled application and if the implementations are not aware of that if might be hard to get such information. I just hope that application developers will not just run media over QUIC DATAGRAM and expect things to work, so that they consider this in their design.

from datagram.

I expect that documents that define media apps over QUIC will explain what signals they need. Apps won't deploy without those new documents. This isn't in scope for this one frame.

from datagram.

Lets go with that expectation.

from datagram.

OK, sounds good to me

from datagram.