Subject: [quicwg/base-drafts] do not normatively specify application delivery order (#257)

From: Patrick McManus <[email-masked]>
Date: Thu, 02 Feb 2017 05:15:18 -0800

for #252 
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/257

-- Commit Summary --

  * streams are ordered but maybe not delivery
  * address 2 more cases

-- File Changes --

    M draft-ietf-quic-transport.md (11)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/257.patch
https://github.com/quicwg/base-drafts/pull/257.diff

-- 
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/pull/257

---

From: ianswett <[email-masked]>
Date: Thu, 02 Feb 2017 08:40:38 -0800

ianswett commented on this pull request.

> @@ -1370,8 +1369,8 @@ abstraction.  Streams can be created either by the client or the server, can
 concurrently send data interleaved with other streams, and can be cancelled.
 QUIC's stream lifetime is modeled closely after HTTP/2's {{?RFC7540}}.  Streams
 are independent of each other in delivery order.  That is, data that is received
-on a stream is delivered in order within that stream, but there is no particular
-delivery order across streams.  Transmit ordering among streams is left to the
+on a stream is ordered within that stream via the frame offset, but there is no particular
+order across streams.  Transmit ordering among streams is left to the
 implementation.  QUIC streams are considered lightweight in that the creation

Not your change, but it seems a bit verbose to talk about how lightweight streams are 3 times in one paragraph.  Maybe we can remove the last sentence("Implementations are therefore advised...")?

> @@ -1612,8 +1611,8 @@ sender or during delivery to the application at the receiver.
 When new data is to be sent on a stream, a sender MUST set the encapsulating
 STREAM frame's offset field to the stream offset of the first byte of this new
 data.  The first byte of data that is sent on a stream has the stream offset 0.
-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
+A receiver MUST ensure that received stream data creates an ordered
+byte-stream.  Data received out of order may need to be buffered for

I believe the purpose of the MUST was to ensure that if a packet with a stream frame is acked, it's not discarded.  The new wording is somewhat ambiguous to me, though I know what you're aiming for.

Also, can we remove "as long as it is not in violation of the receiver's flow control limits."  That causes a connection close error, and mentioning flow control so briefly isn't that helpful.

> @@ -1370,8 +1369,8 @@ abstraction.  Streams can be created either by the client or the server, can
 concurrently send data interleaved with other streams, and can be cancelled.
 QUIC's stream lifetime is modeled closely after HTTP/2's {{?RFC7540}}.  Streams
 are independent of each other in delivery order.  That is, data that is received
-on a stream is delivered in order within that stream, but there is no particular
-delivery order across streams.  Transmit ordering among streams is left to the
+on a stream is ordered within that stream via the frame offset, but there is no particular
+order across streams.  Transmit ordering among streams is left to the
 implementation.  QUIC streams are considered lightweight in that the creation

Also, we don't mention flow control anywhere in this intro section.  Possibly it should be mentioned?

-- 
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/pull/257#pullrequestreview-19829676

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 Feb 2017 17:35:41 -0800

martinthomson commented on this pull request.

I've opened #258 to address your comments.