Subject: [quicwg/base-drafts] Why do we have final size? (#3739)

From: Mike Bishop <[email-masked]>
Date: Fri, 05 Jun 2020 08:57:37 -0700

Fixes #3721.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Why do we have final size?

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3739.patch
https://github.com/quicwg/base-drafts/pull/3739.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/3739

---

From: David Schinazi <[email-masked]>
Date: Fri, 05 Jun 2020 18:00:52 -0700

@DavidSchinazi 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/3739#pullrequestreview-425698925

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 05 Jun 2020 18:08:20 -0700

@kazuho commented on this pull request.

> @@ -908,10 +908,11 @@ final size is the number of bytes sent.  More generally, this is one higher
 than the offset of the byte with the largest offset sent on the stream, or zero
 if no bytes were sent.
 
-For a stream that is reset, the final size is carried explicitly in a
-RESET_STREAM frame.  Otherwise, the final size is the offset plus the length of
-a STREAM frame marked with a FIN flag, or 0 in the case of incoming
-unidirectional streams.
+At the end of a stream, the sender communicates the final size to the recipient,
+ensuring flow control state is synchronized.  For a stream that is reset, the
+final size is carried explicitly in a RESET_STREAM frame.  Otherwise, the final
+size is the offset plus the length of a STREAM frame marked with a FIN flag, or
+0 in the case of incoming unidirectional streams.

To me it seems that the text starting from "or, ..." is confusing. That is because a "sender" does not communicate the final size of incoming undirectional stream, contrary to what the first sentence of this paragraph suggests.

I think it might make sense to either simply drop "or... ", or modify the first sentence to state that such communication is made for streams that has the send side.

-- 
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/3739#pullrequestreview-425699692

---

From: Marten Seemann <[email-masked]>
Date: Fri, 05 Jun 2020 20:53:04 -0700

@marten-seemann 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/3739#pullrequestreview-425710879

---

From: Martin Thomson <[email-masked]>
Date: Sat, 06 Jun 2020 02:42:45 -0700

@martinthomson commented on this pull request.

I think that Kazuho is right regarding unidirectional streams (implying that a nothingness has size is silly), but I would go further.

There are three cases we care about: STREAM w/ data and FIN in which case the final size is offset+length.  We include an offset even when there is no data so that the final size is communicated in that frame.  Then there is RESET_STREAM, which carries the final size.  That way, no matter how the stream transitions to closed, the size is known.  So I would say that:

> The final size of a stream is always signaled to recipient.  Final size is signaled as the sum of the Offset and Length fields of a STREAM frame, noting that the length might be implicit.  Alternatively, the Final Size field of a RESET_STREAM frame carries this value.  This ensures that all ways that a stream can be closed result in the number of bytes on the stream are reliably transmitted. This guarantees that both endpoints agree on how much flow control credit was consumed by 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/3739#discussion_r436254880

---

From: Mike Bishop <[email-masked]>
Date: Mon, 08 Jun 2020 07:12:57 -0700

@MikeBishop pushed 1 commit.

ec07d0f02c467d29ed922309879bd01bf0715d4e  Martin's suggestion, with some editing

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3739/files/24a7163ade984c97d7bf3946b2e0bc81cb93cf34..ec07d0f02c467d29ed922309879bd01bf0715d4e

---

From: Mike Bishop <[email-masked]>
Date: Mon, 08 Jun 2020 07:13:20 -0700

@MikeBishop commented on this pull request.

Mostly took Martin's text.

-- 
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/3739#discussion_r436741405

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 08 Jun 2020 07:42:54 -0700

:+1: LGTM modulo a nitpick.

> @@ -908,10 +908,13 @@ final size is the number of bytes sent.  More generally, this is one higher
 
-For a stream that is reset, the final size is carried explicitly in a
-RESET_STREAM frame.  Otherwise, the final size is the offset plus the length of
-a STREAM frame marked with a FIN flag, or 0 in the case of incoming
-unidirectional streams.
+The final size of a stream is always signaled to the recipient.  The final size
+is the sum of the Offset and Length fields of a STREAM frame with a FIN flag,
+noting that the length might be implicit.  Alternatively, the Final Size field

Maybe "noting that the offset and the length might be implicit"?

This is an editorial nitpick purely from the viewpoint of consistency, but it is a bit surprising to see only one of the two fields called out as might be implicit, even though both of the fields can be omitted.

-- 
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/3739#pullrequestreview-426312353

---

From: Mike Bishop <[email-masked]>
Date: Mon, 08 Jun 2020 11:40:42 -0700

True.  That will only be the case when a stream has only one STREAM frame, so it would be _unusual_ for the final STREAM frame to have an implicit Offset, but it's certainly not prohibited.

-- 
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/3739#discussion_r436914997

---

From: Mike Bishop <[email-masked]>
Date: Mon, 08 Jun 2020 11:41:44 -0700

2b0b2ba4dd626d4992a5ff7bf26f473df9aa4310  Two implicit fields

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3739/files/ec07d0f02c467d29ed922309879bd01bf0715d4e..2b0b2ba4dd626d4992a5ff7bf26f473df9aa4310

---

From: ianswett <[email-masked]>
Date: Mon, 08 Jun 2020 12:26:11 -0700

@ianswett commented on this pull request.

> +of a RESET_STREAM frame carries this value.  This ensures that all ways that a
+stream can be closed result in the number of bytes on the stream being reliably
+transmitted.  This guarantees that both endpoints agree on how much flow control

```suggestion
of a RESET_STREAM frame carries this value.  This ensures all closed streams have a known final size, guaranteeing both endpoints agree on how much flow control
```

-- 
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/3739#pullrequestreview-426553096

---

From: ianswett <[email-masked]>
Date: Mon, 08 Jun 2020 12:29:40 -0700

Some suggestions

+is the sum of the Offset and Length fields of a STREAM frame with a FIN flag,
+noting that these fields might be implicit.  Alternatively, the Final Size field
+of a RESET_STREAM frame carries this value.  This ensures that all ways that a
+stream can be closed result in the number of bytes on the stream being reliably

I don't think this is quite correct, since there's not an implicit fin in the case of a stream where the Fin was never sent and the stream was reset.

```suggestion
The final size of a stream is always signaled to the recipient.  For streams that
are completed, the final size is the sum of the Offset and Length fields of a
STREAM frame with a FIN flag.  For a stream that is reset, the Final Size field
of a RESET_STREAM frame carries the final size.  This ensures that all ways that a
stream can be closed result in the number of bytes on the stream being reliably
```

-- 
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/3739#pullrequestreview-426555319

---

From: Martin Thomson <[email-masked]>
Date: Mon, 08 Jun 2020 19:00:21 -0700

The implicit refers to the Length field, which is implicit when omitted.  Some tweaking might be required for that.

-- 
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/3739#discussion_r437095094

---

From: Marten Seemann <[email-masked]>
Date: Mon, 08 Jun 2020 21:12:26 -0700

@marten-seemann commented on this pull request.

No need to refer to the wire encoding of offset and length, right?
My suggestion: "... is the sum of the offset and the length of a STREAM frame with a FIN flag"

-- 
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/3739#discussion_r437127074

---

From: Mike Bishop <[email-masked]>
Date: Tue, 09 Jun 2020 06:29:20 -0700

Both the Offset and Length fields can be implicit.  As discussed above, it would be unusual (at least with HTTP/3 for both to be implicit, but it's certainly allowed.  I think if the fields specifically get mentioned, the aside that they might be implicit needs to remain.  If we switch to pointing to the values, we could drop that, but it might be confusing to some people.

FIN isn't a field, and isn't contemplated by the aside about implicit fields.

-- 
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/3739#discussion_r437416830

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jun 2020 15:23:29 -0700

Merged #3739 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/3739#event-3427062672