Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Why do we have final size? #3739

Merged
merged 3 commits into from
Jun 9, 2020
Merged

Why do we have final size? #3739

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
24a7163
Why do we have final size?
MikeBishop Jun 5, 2020
ec07d0f
Martin's suggestion, with some editing
MikeBishop Jun 8, 2020
2b0b2ba
Two implicit fields
MikeBishop Jun 8, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -908,10 +908,13 @@ 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.
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 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
Comment on lines +911 to +915
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Suggested change
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 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
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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Contributor Author

@MikeBishop MikeBishop Jun 9, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both the Offset and Length fields can be implicit. As discussed above, it might 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.

transmitted. This guarantees that both endpoints agree on how much flow control
Comment on lines +914 to +916
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
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

credit was consumed by the stream.

An endpoint will know the final size for a stream when the receiving part of the
stream enters the "Size Known" or "Reset Recvd" state ({{stream-states}}).
Expand Down