RE: draft-lubashev-quic-partial-reliability

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I think this proposal largely makes good sense.

Be default no MIN_STREAM_DATA frame is sent which is then the current
stream behaviour.
Any application protocol can define its own rules about which streams can
behave partially reliable.

A counter argument is that QUIC explicitly distinguishes between uni- and
bi-directional streams, so why not between partial- and fully reliable
streams? The answer might be that uni- streams can close state early, while
there is no similar concern for partial reliability.

Another concern is time-based partial reliability. If data is old, don’t
retransmit regardless. But an application protocol can handle this.

My main concern is that sending MIN_FRAME_DATA can generate A LOT of
traffic with lots of tiny messages where you only care about, say, the last
three 1 byte messages sent (hoping at least one gets through). The
MIN_FRAME_DATA could be much larger than the messages forcing less frequent
traffic. Of course, locally you can have you own rules, and just
periodically update MIN_FRAME_DATA, but this is a bit odd.

A variation of the concept could be sending MIN_FRAME_DATA as a delta to
most recent: never expect more than X bytes older than most recently seen,
but that also has it issues when messages are variable length.


As to client vs server asymmetri: It strongly suggest not to make a
distinction here because there are many symmetric peer to peer use cases
and also opposite cases: server to client with partially reliable video,
client to server with partially reliable game state, server to server with
partially reliable gossip protocol to statistically advance a common state
(e.g. "I have processed so many bytes now, how about you?”).


Kind Regards,
Mikkel Fahnøe Jørgensen


On 19 December 2017 at 16.47.08, Lucas Pardue ([e-mail])
wrote:

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