From f1b22608f9adcc6fbdc70fad9e7166fe9108a379 Mon Sep 17 00:00:00 2001 From: Subodh Iyengar Date: Mon, 14 Aug 2017 12:12:30 -0700 Subject: [PATCH 1/5] Clarify and and FIN to flow control This PR has 2 changes: * Clarifies the language around stream and connection flow control and makes it match the flow control section. The one major change from before was that maxData = 10 indicated that you could only send offset till 9, however with the formulation as an offset sending maxOffset = 10 means that you can send offset until 10, i.e. 11 bytes. * Makes FIN bit to be flow controllable. This would reduce one edge case where a packet scheduler does not have to do a special check for whether it only needs to send a FIN when it checks for flow control. This has the advantage of being able to define flow control on a stream in terms of offsets rather than max data. --- draft-ietf-quic-transport.md | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 60a27e1899..f76733d116 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1660,7 +1660,7 @@ Reason Phrase: ## MAX_DATA Frame {#frame-max-data} The MAX_DATA frame (type=0x04) is used in flow control to inform the peer of -the maximum amount of data that can be sent on the connection as a whole. +the maximum offset of data that can be sent on the connection as a whole. The frame is as follows: @@ -1669,19 +1669,18 @@ The frame is as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | -+ Maximum Data (64) + ++ Maximum Offset (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields in the MAX_DATA frame are as follows: -Maximum Data: +Maximum Offset: -: A 64-bit unsigned integer indicating the maximum amount of data that can be - sent on the entire connection, in units of 1024 octets. That is, the updated - connection-level data limit is determined by multiplying the encoded value by - 1024. +: A 64-bit unsigned integer indicating the sum of maximum offset of data that + can be sent across all streams, in units of 1024 octets. That is, the updated + connection-level data limit is determined by multiplying the encoded value by 1024. All data sent in STREAM frames counts toward this limit, with the exception of data on stream 0. The sum of the largest received offsets on all streams - @@ -1695,7 +1694,7 @@ initial limits (see {{zerortt-parameters}}). ## MAX_STREAM_DATA Frame {#frame-max-stream-data} The MAX_STREAM_DATA frame (type=0x05) is used in flow control to inform a peer -of the maximum amount of data that can be sent on a stream. +of the maximum offset that can be sent on a stream. The frame is as follows: @@ -1706,7 +1705,7 @@ The frame is as follows: | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | -+ Maximum Stream Data (64) + ++ Maximum Stream Offset (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ @@ -1717,9 +1716,9 @@ Stream ID: : The stream ID of the stream that is affected. -Maximum Stream Data: +Maximum Stream Offset: -: A 64-bit unsigned integer indicating the maximum amount of data that can be +: A 64-bit unsigned integer indicating the largest data offset that can be sent on the identified stream, in units of octets. When counting data toward this limit, an endpoint accounts for the largest @@ -1728,11 +1727,11 @@ reordering can mean that the largest received offset on a stream can be greater than the total size of data received on that stream. Receiving STREAM frames might not increase the largest received offset. -The data sent on a stream MUST NOT exceed the largest maximum stream data value -advertised by the receiver. An endpoint MUST terminate a connection with a -FLOW_CONTROL_ERROR error if it receives more data than the largest maximum -stream data that it has sent for the affected stream, unless this is a result of -a change in the initial limits (see {{zerortt-parameters}}). +The largest offset sent on a stream MUST NOT exceed the largest maximum stream offset +value advertised by the receiver. For consistency, the FIN is also subject to this limit. +An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR error if it receives more +data than the largest maximum stream data that it has sent for the affected stream, unless +this is a result of a change in the initial limits (see {{zerortt-parameters}}). ## MAX_STREAM_ID Frame {#frame-max-stream-id} From c22e84b1c2b0363bd3466e0387c935daea8a2f0e Mon Sep 17 00:00:00 2001 From: Subodh Iyengar Date: Mon, 14 Aug 2017 12:52:19 -0700 Subject: [PATCH 2/5] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f76733d116..06178f8d8a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1728,7 +1728,7 @@ than the total size of data received on that stream. Receiving STREAM frames might not increase the largest received offset. The largest offset sent on a stream MUST NOT exceed the largest maximum stream offset -value advertised by the receiver. For consistency, the FIN is also subject to this limit. +value advertised by the receiver. For consistency, the FIN is also subject to this limit. An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR error if it receives more data than the largest maximum stream data that it has sent for the affected stream, unless this is a result of a change in the initial limits (see {{zerortt-parameters}}). From 7b430584bcc40636a82c3ffd01b581f3a7408709 Mon Sep 17 00:00:00 2001 From: Subodh Iyengar Date: Mon, 14 Aug 2017 19:55:01 -0700 Subject: [PATCH 3/5] Update draft-ietf-quic-transport.md Change PR to reflect mailing list discussion --- draft-ietf-quic-transport.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 06178f8d8a..966a6a7e84 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1727,11 +1727,11 @@ reordering can mean that the largest received offset on a stream can be greater than the total size of data received on that stream. Receiving STREAM frames might not increase the largest received offset. -The largest offset sent on a stream MUST NOT exceed the largest maximum stream offset -value advertised by the receiver. For consistency, the FIN is also subject to this limit. -An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR error if it receives more -data than the largest maximum stream data that it has sent for the affected stream, unless -this is a result of a change in the initial limits (see {{zerortt-parameters}}). +The largest offset sent on a stream MUST be less than the largest maximum stream offset +value advertised by the receiver. An endpoint MUST terminate a connection with a +FLOW_CONTROL_ERROR error if it receives more data than the largest maximum stream +data that it has sent for the affected stream, unless this is a result of a change +in the initial limits (see {{zerortt-parameters}}). ## MAX_STREAM_ID Frame {#frame-max-stream-id} From bb58a5eb746d450ee440c0dd1a8066cf3f263864 Mon Sep 17 00:00:00 2001 From: Subodh Iyengar Date: Mon, 14 Aug 2017 22:59:29 -0700 Subject: [PATCH 4/5] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 966a6a7e84..a8982aa22b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1678,7 +1678,7 @@ The fields in the MAX_DATA frame are as follows: Maximum Offset: -: A 64-bit unsigned integer indicating the sum of maximum offset of data that +: A 64-bit unsigned integer indicating the sum of maximum offset of data that can be sent across all streams, in units of 1024 octets. That is, the updated connection-level data limit is determined by multiplying the encoded value by 1024. From 7b6a98c54270ecaf9a6552bf1ad09a3489729d0a Mon Sep 17 00:00:00 2001 From: Subodh Iyengar Date: Mon, 14 Aug 2017 23:38:45 -0700 Subject: [PATCH 5/5] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a8982aa22b..70f1ef4919 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1680,7 +1680,8 @@ Maximum Offset: : A 64-bit unsigned integer indicating the sum of maximum offset of data that can be sent across all streams, in units of 1024 octets. That is, the updated - connection-level data limit is determined by multiplying the encoded value by 1024. + connection-level data limit is determined by multiplying the encoded value by + 1024. All data sent in STREAM frames counts toward this limit, with the exception of data on stream 0. The sum of the largest received offsets on all streams - @@ -1727,11 +1728,11 @@ reordering can mean that the largest received offset on a stream can be greater than the total size of data received on that stream. Receiving STREAM frames might not increase the largest received offset. -The largest offset sent on a stream MUST be less than the largest maximum stream offset -value advertised by the receiver. An endpoint MUST terminate a connection with a -FLOW_CONTROL_ERROR error if it receives more data than the largest maximum stream -data that it has sent for the affected stream, unless this is a result of a change -in the initial limits (see {{zerortt-parameters}}). +The largest offset sent on a stream MUST be less than the largest maximum +stream offset value advertised by the receiver. An endpoint MUST terminate a +connection with a FLOW_CONTROL_ERROR error if it receives more data than the +largest maximum stream data that it has sent for the affected stream, unless +this is a result of a change in the initial limits (see {{zerortt-parameters}}). ## MAX_STREAM_ID Frame {#frame-max-stream-id}