Subject: [quicwg/base-drafts] why require in order delivery? (#252)

From: Patrick McManus <[email-masked]>
Date: Tue, 31 Jan 2017 07:01:24 -0800

transport 9.4 contains: "A receiver MUST ensure that received stream data is delivered to the application as an ordered byte-stream. Data received out of order MUST be buffered for later delivery, as long as it is not in violation of the receiver’s flow control limits."

I agree QUIC provides an ordered byte stream abstraction, but why do we have this requirement about in-order delivery to the application? Surely that makes a lot of sense, but it seems to me the only real requirement is that it be a byte stream because boundaries are not preserved..

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/252

---

From: ianswett <[email-masked]>
Date: Tue, 31 Jan 2017 07:22:22 -0800

Possibly "A receiver MUST allow received stream data to be delivered to the application as an ordered byte-stream."  For crypto and other purposes, an in order byte-stream is a necessary feature, but I agree that one could imagine out of order delivery to the application.  

With lightweight streams, I think this use case is weak, but I don't see any reason to specifically forbid it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/252#issuecomment-276392679

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jan 2017 15:40:57 -0800

I had the same comment.  Someone once told me that in-order delivery was a choice that the receiver made, not a requirement on the protocol.  At least in the abstract.

The only catch here is that flow control assumes in-order delivery.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/252#issuecomment-276529643

---

From: krasic <[email-masked]>
Date: Tue, 31 Jan 2017 16:35:47 -0800

Just to echo and rephrase Ian's point.   Streams are light weight.   So the
receiver does have a choice:  if in-order is too strong, then send
"messages" on separate streams.

A example that's come up a few times: media streaming.  If you want
"partial reliability", make every audio or video frame* it's own QUIC
stream.  Then you can have a way to deal with individual media frames that
are too late and ignore/cancel them.    You could also express priorities,
e.g. certain types of frame to be more important (e.g. I frames in MPEG
like video).

*ambiguity alert:  media streaming != QUIC stream, video frame != QUIC
frame.

On Tue, Jan 31, 2017 at 3:40 PM, Martin Thomson <[email-masked]>
wrote:

> I had the same comment. Someone once told me that in-order delivery was a
> choice that the receiver made, not a requirement on the protocol. At least
> in the abstract.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/252#issuecomment-276529643>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGIAhqftd2RAHEkTrQbKq0jTHIPU16mpks5rX8aJgaJpZM4LyviU>
> .
>

-- 
Charles 'Buck' Krasic | Software Engineer | [email-masked] | +1 (408)
412-1141

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/252#issuecomment-276539139