Subject: Re: [quicwg/base-drafts] Editorial suggestions on the Streams section (#2730)

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 19:12:56 -0700

@ianswett pushed 1 commit.

483a757fccc57d323349b3821f23ad7fa561ddd3  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2730/files/fed5f29eb369d133f7c40d901576c9debb0be9f1..483a757fccc57d323349b3821f23ad7fa561ddd3

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 19:17:44 -0700

ianswett commented on this pull request.

Thanks Martin, I made some updates based on your suggestions.

> @@ -187,8 +187,9 @@ QUIC:
 
 QUIC packet:
 
-: The smallest unit of QUIC that can be encapsulated in a UDP datagram. Multiple
-  QUIC packets can be encapsulated in a single UDP datagram.
+: A complete processable payload with a packet type, encryption level and

Payload was my best suggestion here, so I'm open to others.

> @@ -244,8 +245,9 @@ x (*) ...:
 # Streams {#streams}
 
 Streams in QUIC provide a lightweight, ordered byte-stream abstraction to an
-application. An alternative view of QUIC streams is as an elastic "message"
-abstraction.
+application. Streams can be unidirectional or bidirecational.  An alternative
+view of QUIC unidirectional streams is a "message" abstraction of unlimited
+length.

practically unlimited?

> @@ -543,9 +546,8 @@ MAX_STREAM_DATA frames, it only receives any retransmissions of stream data.
 
 Once all data for the stream has been received, the receiving part enters the
 "Data Recvd" state.  This might happen as a result of receiving the same STREAM
-frame that causes the transition to "Size Known".  In this state, the endpoint
-has all stream data.  Any STREAM or STREAM_DATA_BLOCKED frames it receives for
-the stream can be discarded.
+frame that causes the transition to "Size Known".  Any STREAM or
+STREAM_DATA_BLOCKED frames it receives for the stream can be discarded.

Updated, PTAL

> @@ -734,9 +731,8 @@ used to check for flow control violations. A receiver might use a sum of bytes
 consumed on all streams to determine the maximum data limit to be advertised.
 
 A receiver can advertise a larger offset by sending MAX_STREAM_DATA or MAX_DATA
-frames at any time during the connection.  A receiver cannot renege on an
-advertisement however.  That is, once a receiver advertises an offset, it MAY
-advertise a smaller offset, but this has no effect.
+frames.  That is, once a receiver advertises an offset, it MAY advertise a

Done

> @@ -746,16 +742,15 @@ A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do not increase
 flow control limits.
 
 If a sender runs out of flow control credit, it will be unable to send new data
-and is considered blocked.  A sender SHOULD send STREAM_DATA_BLOCKED or
-DATA_BLOCKED frames to indicate it has data to write but is blocked by flow
+and is considered blocked.  A sender SHOULD send a single STREAM_DATA_BLOCKED or

Done

> @@ -861,13 +855,12 @@ If either is received, the connection MUST be closed immediately with a
 connection error of type STREAM_LIMIT_ERROR (see {{immediate-close}}).
 
 Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that
-receives a STREAM frame with a stream ID exceeding the limit it has sent MUST
+receives a frame with a stream ID exceeding the limit it has sent MUST

That's true, but I think that's a feature, not a bug.

> @@ -657,11 +659,6 @@ RESET_STREAM frame it sends, but MAY use any application error code.  The
 endpoint that sends a STOP_SENDING frame MAY ignore the error code carried in
 any RESET_STREAM frame it receives.
 
-If the STOP_SENDING frame is received on a stream that is already in the
-"Data Sent" state, an endpoint that wishes to cease retransmission of
-previously-sent STREAM frames on that stream MUST first send a RESET_STREAM
-frame.

Upon reading, I thought it was redundant with the surrounding text, but I'll restore it for this PR.

-- 
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/2730#pullrequestreview-251435943

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 19:20:28 -0700

e87958746169b877b3060c1ce5aaf7b6a020d514  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2730/files/483a757fccc57d323349b3821f23ad7fa561ddd3..e87958746169b877b3060c1ce5aaf7b6a020d514

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 19:26:08 -0700

f546d201e4fb7b11a11bcafcd0a203c8e7a9a8cb  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2730/files/e87958746169b877b3060c1ce5aaf7b6a020d514..f546d201e4fb7b11a11bcafcd0a203c8e7a9a8cb

---

From: MikkelFJ <[email-masked]>
Date: Tue, 18 Jun 2019 23:28:12 -0700

mikkelfj commented on this pull request.

 QUIC packet:
 
-: The smallest unit of QUIC that can be encapsulated in a UDP datagram. Multiple
-  QUIC packets can be encapsulated in a single UDP datagram.
+: A complete processable payload with a packet type, encryption level and
+  packet number. Multiple QUIC packets can be encapsulated in a single UDP
+  datagram.

An authenticated and encrypted container of payload usually carrying a packet number and sometimes a connection identifier and version information in its header.

-- 
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/2730#pullrequestreview-251495310

---

From: MikkelFJ <[email-masked]>
Date: Tue, 18 Jun 2019 23:30:01 -0700

# Streams {#streams}

```suggestion
Streams in QUIC provide a lightweight, ordered reliable byte-stream abstraction to an
```

-- 
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/2730#pullrequestreview-251495871

---

From: MikkelFJ <[email-masked]>
Date: Tue, 18 Jun 2019 23:32:35 -0700

> @@ -335,8 +337,9 @@ the flow control limits set by its peer.  Flow control is described in detail in
 Stream multiplexing can have a significant effect on application performance if
 resources allocated to streams are correctly prioritized.
 
-QUIC does not provide frames for exchanging prioritization information.  Instead
-it relies on receiving priority information from the application that uses QUIC.
+QUIC does not provide a mechanism for exchanging prioritization information.
+Instead it relies on receiving priority information from the application that
+uses QUIC.

```suggestion
uses QUIC in an implementation specific manner.
```

-- 
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/2730#pullrequestreview-251496654

---

From: Mike Bishop <[email-masked]>
Date: Wed, 19 Jun 2019 09:29:32 -0700

MikeBishop commented on this pull request.

 QUIC packet:

Structure?  Sequence of octets?  Or drop it entirely and define a packet as a header, payload, and authentication tag in that order.

```suggestion
Instead, it relies on receiving priority information from the application that
```

implementation-specific, with the hyphen

> @@ -543,9 +546,9 @@ MAX_STREAM_DATA frames, it only receives any retransmissions of stream data.
 
 Once all data for the stream has been received, the receiving part enters the
 "Data Recvd" state.  This might happen as a result of receiving the same STREAM
-frame that causes the transition to "Size Known".  In this state, the endpoint
-has all stream data.  Any STREAM or STREAM_DATA_BLOCKED frames it receives for
-the stream can be discarded.
+frame that causes the transition to "Size Known".  After all data has been
+received, Any STREAM or STREAM_DATA_BLOCKED frames it receives for the stream

```suggestion
received, any STREAM or STREAM_DATA_BLOCKED frames for the stream
```

-- 
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/2730#pullrequestreview-251820000

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Jun 2019 09:00:06 -0700

martinthomson approved this pull request.

-- 
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/2730#pullrequestreview-252384893

---

From: ianswett <[email-masked]>
Date: Fri, 21 Jun 2019 10:34:06 -0700

QUIC packet:

Thanks Mike, I updated it to header, payload, and authentication tag.

-- 
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/2730#discussion_r296328566

---

From: ianswett <[email-masked]>
Date: Fri, 21 Jun 2019 10:38:59 -0700

4c32ea380a03eedc43e7413418926bc520524724  Mike's comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2730/files/f546d201e4fb7b11a11bcafcd0a203c8e7a9a8cb..4c32ea380a03eedc43e7413418926bc520524724

---

From: ianswett <[email-masked]>
Date: Fri, 21 Jun 2019 10:39:29 -0700

Thanks Mike, I addressed or accepted most of your comments.

 # Streams {#streams}

I'm not sure I want to make that change and I'm not changing that sentence at the moment, so if you would like to change it, I'd suggest a separate PR.

I added this, then removed it because it read somewhat redundantly.

-- 
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/2730#pullrequestreview-252946609

---

From: Mike Bishop <[email-masked]>
Date: Fri, 21 Jun 2019 11:14:17 -0700

Perhaps, but wouldn't this then be a design change? This is an editorial PR.

-- 
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/2730#discussion_r296342344

---

From: ianswett <[email-masked]>
Date: Fri, 21 Jun 2019 11:24:37 -0700

Fair point, I'll revert that and if we think it's worth changing, I'll open a design issue for 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/pull/2730#discussion_r296345900

---

From: ianswett <[email-masked]>
Date: Fri, 21 Jun 2019 11:25:52 -0700

fea52b2ff749fe073c46fb5d34656e365bec4210  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2730/files/4c32ea380a03eedc43e7413418926bc520524724..fea52b2ff749fe073c46fb5d34656e365bec4210

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jun 2019 15:24:26 -0700

martinthomson commented on this pull request.

> @@ -187,9 +187,9 @@ QUIC:
 
 QUIC packet:
 
-: A complete processable payload with a packet type, encryption level and
-  packet number. Multiple QUIC packets can be encapsulated in a single UDP
-  datagram.
+: A complete processable unit of QUIC consisting of a header, payload, and
+  authentication tag.  Multiple QUIC packets can be encapsulated in a single

Not all packets have an authentication tag.  A single atomic unit is really the only thing we can say.

-- 
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/2730#pullrequestreview-254301367

---

From: ianswett <[email-masked]>
Date: Tue, 25 Jun 2019 15:30:54 -0700

bbe2b80d490c39c1d5900a5f00b4bbe11a29c4df  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2730/files/fea52b2ff749fe073c46fb5d34656e365bec4210..bbe2b80d490c39c1d5900a5f00b4bbe11a29c4df

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jun 2019 15:31:48 -0700

Merged #2730 into master.

-- 
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/2730#event-2439123183