Partial reliability is an attractive addition to frame/stream transport. By setting a timer before calling writer.write(), it is possible to give up on a "discardable frame" (a non-base layer frame) after it has taken too long to send.
The issue is that RESET_STREAM may not be uniformly implemented in QUIC stacks. RFC 9000 Section 19.4 says:
"After sending a RESET_STREAM, an endpoint ceases transmission and retransmission of STREAM frames on the identified stream. A receiver of RESET_STREAM can discard any data that it already received on that stream."
Note the lack of normative language with respect to receive-side processing, where RFC 9000 Section 3.2 does not require that RESET_STREAM be immediately surfaced to the application.
The handling of RESET_STREAM frames also affects relays, which may immediately process a RESET_STREAM frame on receipt, forwarding it on and not forwarding subsequently received data, or alternatively, could forward incoming data in the order it was received, including RESET_STREAM frames.
These issues appear to be affecting the demo application. RESET_STREAM frames are sent when the RTO timer expires, but even when writer.abort() is called, frames typically arrive intact anyway.
Partial reliability is an attractive addition to frame/stream transport. By setting a timer before calling
writer.write(), it is possible to give up on a "discardable frame" (a non-base layer frame) after it has taken too long to send.Live Demo: https://webrtc.internaut.com/wc/wtSender10/ Code: async function writeChunk(transport, chunk, rto, info)
The issue is that
RESET_STREAMmay not be uniformly implemented in QUIC stacks. RFC 9000 Section 19.4 says:"After sending a
RESET_STREAM, an endpoint ceases transmission and retransmission of STREAM frames on the identified stream. A receiver ofRESET_STREAMcan discard any data that it already received on that stream."Note the lack of normative language with respect to receive-side processing, where RFC 9000 Section 3.2 does not require that
RESET_STREAMbe immediately surfaced to the application.The handling of
RESET_STREAMframes also affects relays, which may immediately process aRESET_STREAMframe on receipt, forwarding it on and not forwarding subsequently received data, or alternatively, could forward incoming data in the order it was received, includingRESET_STREAMframes.These issues appear to be affecting the demo application.
RESET_STREAMframes are sent when the RTO timer expires, but even whenwriter.abort()is called, frames typically arrive intact anyway.Related: https://github.com/w3c/webtransport/issues/422