Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transport: Partial reliability #4

Open
aboba opened this issue Oct 13, 2022 · 0 comments
Open

Transport: Partial reliability #4

aboba opened this issue Oct 13, 2022 · 0 comments

Comments

@aboba
Copy link
Collaborator

aboba commented Oct 13, 2022

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 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.

Related: w3c/webtransport#422

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant