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

[Martin Thomson <[e-mail]>]

@martinthomson 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.

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