RE: Partially Reliable Message Stream

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

Thanks for the review, Mike!

Yes, you got the purpose of the gap exactly right.

> Conflict in the doc.

Actually, I do not see a conflict, but it is true that the accounting is tricky, and the wording could be a bit better. The receiver maintains two distinct variables:
* smallest receive offset -- the smallest offset it is waiting for
* largest received offset -- just what it says, probably used for nothing else by the receiver but verifying compliance with flow control (important, since "largest received offset" - "smallest receive offset" = "size of in-use receive buffer" for the stream).

The quotation from section 5 says that when a new STREAM frame is received, data at offsets smaller than "smallest receive offset" should be discarded (since the receiver should not care for it anymore -- it is expired), but "largest received offset" should still advance if needed (since data has been received -- compliance with flow control is still required for STREAM frames).

-----Original Message-----
From: Mike Bishop [[e-mail]]
Received: Wednesday, 30 May 2018, 6:47PM
To: Lubashev, Igor [[e-mail]]; QUIC WG [[e-mail]]
Subject: RE: Partially Reliable Message Stream

I find the one octet gap a bit confusing, but as I think about it, I see why you need it.  If all the stream data arrived successfully (but hadn't been acknowledged yet due to loss of the ACK, delay, etc.) and the EXPIRED_STREAM_DATA gets lost, the receiver can only retroactively realize there was a jump.  Having an octet that is never transmitted ensures the receiver actually sees a gap, which means that an in-order API will not proceed until it has received either the missing octet or an EXPIRED_STREAM_DATA informing it the octet will never arrive.

This simplification (versus -02) comes at a price:  If an API were exposing stream data out-of-order, then in your example, the receiver knows that a message always begins on a ten-byte boundary.  A receiver can no longer find ten-byte boundaries, because the offset on the read side doesn't match the offset on the send side.  I agree with you that this seems like a reasonable trade-off for the simpler flow control.

One conflict I see in the doc:

*         Section 3 says:  Receipt of an EXPIRED_STREAM_DATA does not advance the largest received offset for the stream.

  *   Section 5 says:  A receiver SHOULD discard any stream data received for an offset smaller than the new smallest receive offset, possibly advancing the largest received offset for the stream.

Other minor nits are better done via PR.
From: QUIC <[e-mail]> On Behalf Of Lubashev, Igor
Sent: Wednesday, May 30, 2018 9:45 AM
To: QUIC WG <[e-mail]>
Subject: Partially Reliable Message Stream

I've just uploaded a new draft for partially reliable QUIC streams.  Note: this feature is likely not in scope for V1, but it can be an extension for V1 and/or a part of V2.

The new version 03 (https://tools.ietf.org/html/draft-lubashev-quic-partial-reliability-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dlubashev-2Dquic-2Dpartial-2Dreliability-2D03&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=_kwXz2JdtqD8uvvd8h8cZ-GQ3_FgDf7dRoorJ-DYVhg&s=t0au9Hcc2L02NXlpLb99Y4e-72lBv2kC2hHZuGifUWg&e=>) no longer needs complex flow control changes and removes the need to transmit multiple frames in the same packet.


  *   Igor

P.S.
  There is also a new version 02, which includes a more complex algorithm with more features and different trade-offs.  But I think version 03 is a better match for the needs so far.