RE: draft-lubashev-quic-partial-reliability

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

Thanks Lucas!

Yes, I have seen other proposals, and this is my alternative.

The idea is that all streams, other than stream 0, can be partially reliable, in both directions, without a need to negotiate (other than version negotiation, in case the initial QUIC version does not support this).

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.

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.

- Igor

-----Original Message-----
From: Lucas Pardue [[e-mail]]
Received: Tuesday, 19 Dec 2017, 4:38AM
To: Lubashev, Igor [[e-mail]]; QUIC WG [[e-mail]]
Subject: RE: draft-lubashev-quic-partial-reliability

Hi Igor,

Thanks for wrting this up, it is an interesting proposal. It seems flexible enough to apply to a few different use cases, although I do wonder how expressive or accommodating APIs could be.

Some basic questions:

Is this proposal the "alternative single-stream method"? I think it is but may be assuming incorrectly.

With this proposal, partial reliability seems to unilaterally apply to all streams, based on the potential reception of the MIN_STREAM_DATA frame at any point during the connection lifetime. This seems a different approach than others where the reliability type is indicated on stream creation. Could this feature be negotiated for the connection (or path ;) )? I can see a case for simplistic client in constrained devices that may not want the overhead of supporting this feature.

Similar to above, is this capability symmetric? Could it be restricted to one direction of traffic?

What stream are MIN_STREAM_DATA frames sent on? Could the stream ID field be omitted if the frame is only sent on the stream it affects?
________________________________________
From: QUIC [[e-mail]] on behalf of Lubashev, Igor [[e-mail]]
Sent: 19 December 2017 03:39
To: QUIC WG
Subject: draft-lubashev-quic-partial-reliability

I’ve just posted a draft on adding partial reliability to QUIC streams.

Datatracker link: https://tools.ietf.org/html/draft-lubashev-quic-partial-reliability
Github link: https://github.com/igorlord/draft-lubashev-quic-partial-reliability

This draft introduces a generic way to add partial reliability to QUIC streams using a single new frame: MIN_STREAM_FRAME (and keeping one new per-stream variable: Min Stream Offset).

The high-level idea is that the sender keeps track of messages within a stream and can “expire” old messages whenever it wants.  The “expiration” is a signal to the transport to not retransmit expired data (and a signal to the other endpoint that this data will not be retransmitted).  All details are in the draft.

I am very interested in feedback on this proposal.


  *   Igor



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------