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.

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

Octets that are sent twice #1353

Merged
merged 4 commits into from May 15, 2018
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
17 changes: 10 additions & 7 deletions draft-ietf-quic-transport.md
Expand Up @@ -3614,13 +3614,16 @@ data. The first octet of data on a stream has an offset of 0. An endpoint is
expected to send every stream octet. The largest offset delivered on a stream
MUST be less than 2^62.

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
later delivery, as long as it is not in violation of the receiver's flow control
limits. An endpoint could receive the same octets multiple times; octets that
have already been received can be discarded. The value for a given octet MUST
NOT change if it is sent multiple times; an endpoint MAY treat receipt of a
changed octet as a connection error of type PROTOCOL_VIOLATION.
QUIC makes no specific allowances for partial reliability or delivery of stream
data out of order. Endpoints are expected to deliver stream data to an
application as an ordered byte-stream. Delivering an order byte-stream requires
Copy link
Contributor

Choose a reason for hiding this comment

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

in-order byte stream?

Copy link
Contributor

Choose a reason for hiding this comment

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

Or ordered?

that an endpoint buffer any data that is received out of order, up to the
advertised flow control limit.

An endpoint could receive the same octets multiple times; octets that have
already been received can be discarded. The value for a given octet MUST NOT
change if it is sent multiple times; an endpoint MAY treat receipt of a changed
octet as a connection error of type PROTOCOL_VIOLATION.

An endpoint MUST NOT send data on any stream without ensuring that it is within
the data limits set by its peer. The cryptographic handshake stream, Stream 0,
Expand Down