RE: draft-lubashev-quic-partial-reliability

["Lubashev, Igor" <[e-mail]>]

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

Yes, this is an application concern, since only the application can know what “old” means.  Also, since MIN_FRAME_DATA  frame is emitted ONLY if some expired stream data is lost (not ACKed), you would not expect to see many such frames on the wire, even if messages keep expiring all the time.



  *   My main concern is that sending MIN_FRAME_DATA [sic: MIN_STREAM_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

This is the most expensive case for MIN_STREAM_DATA – many partially-reliable streams, each carrying 1-byte messages, with each new message expiring all earlier messages, over a high-loss connection.  In this case, the cost of MIN_STREAM_DATA could approach 50% of the cost of the other frames (9 bytes for STREAM + some ACKs vs 5 bytes for MIN_STREAM_DATA frames).

You remove any of the conditions above, and MIN_STREAM_DATA cost drop off rapidly:

  *   Few partially-reliable streams: either multiple messages get consolidated into a single STREAM frame (requiring a single M_S_D frame to expire) or the overhead of the QUIC packet itself (MAC+IP+UDP+QUIC headers) starts to dominate dramatically.
  *   Multi-byte messages: STREAM frames are larger, so M_S_D frame’s proportion is smaller
  *   New messages expiring NOT all earlier messages: more chance for the network to retransmit lost messages, reducing how often M_S_D is sent.
  *   Low-loss connection: few packets are lost, so few M_S_D frames need sending.

“Partially reliable” is not “unreliable”.  The transport still provides message atomicity and ordering guarantees, in addition to retransmission of “still current” data.

If you want completely unreliable (like UDP), you may want something slightly different.  For example, we may decide that is the first STREAM has OFF=1 and Offset=0, this introduces a “completely unreliable” stream.  No retransmissions are expected at all.  However, you still want to do something for flow control (you need to periodically synchronize your stream and connection flow control).  Maybe, if your unreliable stream went idle with the last transmission unacknowledged, you could send a STREAM frame with LEN=1, Length=0, and OFF=1, Offset=current_stream_offset.

If you like this, I can write this in a draft.


  *   Igor


From: Mikkel Fahnøe Jørgensen [mailto:[e-mail]]
Sent: Tuesday, December 19, 2017 12:15 PM
To: Lucas Pardue <[e-mail]>; Lubashev, Igor <[e-mail]>; [e-mail]
Subject: RE: draft-lubashev-quic-partial-reliability

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]<mailto:[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