You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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_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 ofRESET_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 aRESET_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, includingRESET_STREAM
frames.These issues appear to be affecting the demo application.
RESET_STREAM
frames are sent when the RTO timer expires, but even whenwriter.abort()
is called, frames typically arrive intact anyway.Related: w3c/webtransport#422
The text was updated successfully, but these errors were encountered: