Add support for unreliability (with an attribute)

[pthatcherg]

Via a flag called QuicStream.reliable

[martinthomson]

What QUIC are you talking about here?

[lgrahl]

There are a lot of question marks:

1. Is this a proprietary extension solely existing in the W3C API? Or should it be brought into an IETF WG?
2. What exactly is unreliable? The whole stream or the individual frames?
3. If the individual frames are unreliable, how is it supposed to work as a stream? A read operation could splice two completely different frames together and the application would have to add its own framing protocol. That would be awkward. A possibility would be changing this API into a stream of frames (where a frame is just a byte-stream) similarly to what we are planning for SCTP-based data channels.

[pthatcherg]

I wasn't sure if it was best to specify the mechanism in the spec or to leave it up to implementations, but here's the mechanism we have in Chromium already (although not exposed to the Web API yet): if you detect you need to retransmit, abort writing to the stream (send RST_STREAM).

So as two Martin's question: this is standard QUIC, nothing special.

As to Lennart's questions:

1. This is not an extension. It's exactly the same as if the JS called abortWriting() (or the WHATWG stream equivalent). However, if a future extension were added, it could be used as well (which is one reason I thought it would better to not bake the mechanism into the spec).

2. With this mechanism, any loss in the stream would cause the rest of the stream to be lost, but the part before the loss may not be... lost. This obviously works much better for lost of small streams and not few big ones, but that seems just fine for the uses cases where unreliability came up.

3. Yes, that sounds pretty awkward, which is why that's not what the mechanism means.

I suppose we could call the attribute "abortWritingWhenLossDetected" of something like that. But then we'd be baking in the mechanism and closing ourselves off to future mechanisms that might be added.

[aboba]

@lgrahl There is support for partially reliable streams in the current QUIC transport draft, and there is an Issue open in the QUIC applicability draft to explain this:
quicwg/ops-drafts#15

Note that there is also a (distinct) proposal for a datagram extension:
https://datatracker.ietf.org/meeting/103/materials/slides-103-quic-unreliable-datagram-extension

[lgrahl]

My two cents: I believe this goes beyond the original intent of this API. IIRC it was intended to be a low-level API for a QUIC transport, so it should reflect the QUIC transport and its streams via an API that feels native to JS developers but not provide additional abstractions/features (as for example RTCDataChannel is for SCTP). Additionally, if it can be achieved easily by writing and then aborting, then this abstraction is fairly redundant.

Edit: Also, thanks for sharing the slides. This looks promising (although I'd like datagrams across different streams).

[pthatcherg]

In reply to Bernard: where is there support for unreliability in existing drafts? The issue you link to (quicwg/ops-drafts#15) seems to link to another issue (quicwg/ops-drafts#54) which approaches streams as messages, which is more like our approach to unreliability.

In reply to Lennart: I agree we should avoid much abstraction and leave things up to JS to do. In this case, however, that would require some kind of event from the browser to JS letting it know, on a per-stream basis, when retransmission is necessary. And then JS might not respond quickly enough to prevent the retransmission. And it might prevent us from using other retransmission mechanisms in the future.