RE: draft-lubashev-quic-partial-reliability

[Lucas Pardue <[e-mail]>]

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.
-----------------------------