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

Adding unidirectional streams #656

Closed
wants to merge 4 commits into from
Closed

Adding unidirectional streams #656

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
ddb9802
Adding unidirectional streams
ianswett Jun 23, 2017
d254f76
Update
ianswett Jun 23, 2017
fee594a
Update draft-ietf-quic-transport.md
ianswett Jun 29, 2017
0dbd1f8
Trailing whitespace
ianswett Jun 29, 2017
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
9 changes: 6 additions & 3 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -884,8 +884,8 @@ explained in more detail as they are referenced later in the document.
| 0x09 | STREAM_BLOCKED | {{frame-stream-blocked}} |
| 0x0a | STREAM_ID_NEEDED | {{frame-stream-id-needed}} |
| 0x0b | NEW_CONNECTION_ID | {{frame-new-connection-id}} |
| 0xa0 - 0xbf | ACK | {{frame-ack}} |
| 0xc0 - 0xff | STREAM | {{frame-stream}} |
| 0x60 - 0x7f | ACK | {{frame-ack}} |
| 0x80 - 0xff | STREAM | {{frame-stream}} |
{: #frame-types title="Frame Types"}

# Life of a Connection
Expand Down Expand Up @@ -1610,7 +1610,7 @@ entropy on demand, which should be adequate protection against most
opportunistic acknowledgement attacks.

The type byte for a ACK frame contains embedded flags, and is formatted as
`101NLLMM`. These bits are parsed as follows:
`011NLLMM`. These bits are parsed as follows:

* The first three bits must be set to 101 indicating that this is an ACK frame.

Copy link
Contributor

Choose a reason for hiding this comment

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

101 should be 011, I suppose...

Expand Down Expand Up @@ -2577,6 +2577,9 @@ the data limits set by its peer. The cryptographic handshake stream, Stream 0,
is exempt from the connection-level data limits established by MAX_DATA. Stream
0 is still subject to stream-level data limits and MAX_STREAM_DATA.

If a STREAM frame is received for a stream that was previously specified as
unidirectional, the connection MUST be closed with QUIC_INVALID_FRAME_DATA.
Copy link
Member

Choose a reason for hiding this comment

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

I don't follow this. Surely the initiator of a unidirectional stream can send STREAM frames on it (and hence the receivin end is expected to receive frames). Are you trying to say that reception of a STREAM frame, by the initiator of the unidirectional stream, on that stream, is forbidden and should result in a closed connection?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this was worded terribly, I attempted to fix it. Please tell me if it makes sense now.


Flow control is described in detail in {{flow-control}}, and congestion control
is described in the companion document {{QUIC-RECOVERY}}.

Expand Down