RE: draft-lubashev-quic-partial-reliability

[Lucas Pardue <[e-mail]>]

Igor wrote:

The bookkeeping is simple enough and the runtime resources required is just one uint64_t per steam, so I do not see a problem for constrained devices.
Ultimately, partial reliability is a feature that an application either needs or does not. If an application needs it, it most likely requires it. In any case, an application can do its own negotiation if it desires to do so. For example, it can use stream 1 for that.
Now I understand this is connection-wide, I generally agree. However, for something like conventional HTTP/QUIC, the reliable guarantee assurances are required by the mapping. If partial reliability is default enabled transport feature, applications like HTTP/QUIC must restrict or disable it - I'm not sure if the editors/drafts have broached that subject yet (I've certainly had some feedback on my draft about such restrictions).

I did not fully understand the last question. Are you asking whether it is possible for the connection to negotiate just a single stream (in each direction) that would be partially reliable and, therefore, not send a stream id with MIN_STREAM_DATA? I could actually think of a version of MIN_STREAM_DATA that has an implied stream id -- the stream id of a prior/following STREAM frame in the same packet. That would be an optimization that I am happy to add, if there is enough support for it.

Apologies, I hadn't drunk any coffee when first replying and got myself confused. All QUIC frames of this nature should normally include a Stream ID, which identifies the stream it is sent on. I think your suggestion relies on serial ordering/processing (even inside a packet), which might be a hard sell.

Separately, in terms of asymmetry, I was thinking that you might always want (as a policy) clients to transmit with full reliability but provide data to them with partial reliability. I think this is again an application mapping concern.

Regards,
Lucas