From 94754815fe5d11140f77cebe979ff954e8598574 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Fri, 13 Dec 2019 18:19:26 -0800 Subject: [PATCH 1/6] add note on pacing and editorialze --- draft-ietf-quic-transport.md | 55 +++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 23 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8c0f1ee415..353c4b29f0 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -801,33 +801,42 @@ limit is increased. ## Flow Credit Increments {#fc-credit} -This document leaves when and how many bytes to advertise in a MAX_STREAM_DATA -or MAX_DATA frame to implementations, but offers a few considerations. These -frames contribute to connection overhead. Therefore frequently sending frames -with small changes is undesirable. At the same time, larger increments to -limits are necessary to avoid blocking if updates are less frequent, requiring -larger resource commitments at the receiver. Thus there is a trade-off between -resource commitment and overhead when determining how large a limit is -advertised. +Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA +and MAX_DATA frames. This section describes one requirement and offers a few +considerations. -A receiver can use an autotuning mechanism to tune the frequency and amount of -advertised additional credit based on a round-trip time estimate and the rate at -which the receiving application consumes data, similar to common TCP -implementations. As an optimization, sending frames related to flow control -only when there are other frames to send or when a peer is blocked ensures that -flow control doesn't cause extra packets to be sent. +A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before +sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a +sender could be blocked for the rest of the connection if the peer chooses to +not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these +frames, waiting for them means that a sender will be blocked for at least an +entire round trip. If a sender runs out of flow control credit, it will be unable to send new data -and is considered blocked. It is generally considered best to not let the -sender become blocked. To avoid blocking a sender, and to reasonably account -for the possibility of loss, a receiver should send a MAX_DATA or -MAX_STREAM_DATA frame at least two round trips before it expects the sender to -get blocked. +and is considered blocked, resulting in degraded performance. To avoid blocking +a sender, and to reasonably account for the possibility of loss, a receiver can +send a MAX_STREAM_DATA or MAX_DATA frame multiple times within a round trip or +send it early enough to allow for recovery from potential loss before the sender +becomes blocked. + +Control frames contribute to connection overhead. Therefore, frequently sending +MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable. At the +same time, larger increments to limits are necessary to avoid blocking if +updates are less frequent, requiring larger resource commitments at the +receiver. There is a trade-off between resource commitment and overhead when +determining how large a limit is advertised. -A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before -sending MAX_STREAM_DATA or MAX_DATA, since doing so will mean that a sender will -be blocked for at least an entire round trip, and potentially for longer if the -peer chooses to not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. +A receiver can use an autotuning mechanism to tune the frequency and amount of +advertised additional credit based on a round-trip time estimate and the rate at +which the receiving application consumes data, similar to common TCP +implementations. As an optimization, an endpoint could send frames related to +flow control only when there are other frames to send or when a peer is blocked, +ensuring that flow control does not cause extra packets to be sent. + +When a sender receives credit after being blocked, it might send a large amount +of data in response. As is recommended in {{QUIC-RECOVERY}}, implementations +should pace this data to avoid sending it in a burst and causing short-term +network congestion. ## Handling Stream Cancellation {#stream-cancellation} From bb2988130cf981e813f5378b9f908c3b09f134ca Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Sat, 14 Dec 2019 15:13:18 -0800 Subject: [PATCH 2/6] remove pacing recommendation --- draft-ietf-quic-transport.md | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 353c4b29f0..8021d51485 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -812,12 +812,12 @@ not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these frames, waiting for them means that a sender will be blocked for at least an entire round trip. -If a sender runs out of flow control credit, it will be unable to send new data -and is considered blocked, resulting in degraded performance. To avoid blocking -a sender, and to reasonably account for the possibility of loss, a receiver can -send a MAX_STREAM_DATA or MAX_DATA frame multiple times within a round trip or -send it early enough to allow for recovery from potential loss before the sender -becomes blocked. +A sender that runs out of flow control credit will be unable to send new data +and is considered blocked, resulting in degraded performance for the +connection. To avoid blocking a sender and to reasonably account for the +possibility of loss, a receiver can send a MAX_STREAM_DATA or MAX_DATA frame +multiple times within a round trip or send it early enough to allow for recovery +from potential loss. Control frames contribute to connection overhead. Therefore, frequently sending MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable. At the @@ -833,11 +833,6 @@ implementations. As an optimization, an endpoint could send frames related to flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent. -When a sender receives credit after being blocked, it might send a large amount -of data in response. As is recommended in {{QUIC-RECOVERY}}, implementations -should pace this data to avoid sending it in a burst and causing short-term -network congestion. - ## Handling Stream Cancellation {#stream-cancellation} From 6bea25dc982beacbecf4576ff2945a8e89ede4f7 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 16 Dec 2019 21:01:32 -0800 Subject: [PATCH 3/6] add a reference to sec 6.9 without recommendation --- draft-ietf-quic-transport.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8021d51485..57a45eec4f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -833,6 +833,10 @@ implementations. As an optimization, an endpoint could send frames related to flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent. +When a sender receives credit after being blocked, it can send a large amount of +data in response resulting in short-term congestion; see Section 6.9 in +{{QUIC-RECOVERY}} for a discussion of how a sender could avoid this congestion. + ## Handling Stream Cancellation {#stream-cancellation} From b361a8bef74a08a3f29392432648d3450a028037 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 17 Dec 2019 21:47:39 -0800 Subject: [PATCH 4/6] Ian's suggestions --- 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 57a45eec4f..fb36665b93 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -806,25 +806,24 @@ and MAX_DATA frames. This section describes one requirement and offers a few considerations. A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before -sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a -sender could be blocked for the rest of the connection if the peer chooses to -not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these -frames, waiting for them means that a sender will be blocked for at least an -entire round trip. +sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so means that a sender +will be blocked for the rest of the connection if the peer chooses to not send +STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these frames, +waiting for them means that a sender will be blocked for at least an entire +round trip. A sender that runs out of flow control credit will be unable to send new data and is considered blocked, resulting in degraded performance for the -connection. To avoid blocking a sender and to reasonably account for the -possibility of loss, a receiver can send a MAX_STREAM_DATA or MAX_DATA frame -multiple times within a round trip or send it early enough to allow for recovery -from potential loss. +connection. To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or +MAX_DATA frame multiple times within a round trip or send it early enough to +allow for recovery from loss of the frame. Control frames contribute to connection overhead. Therefore, frequently sending -MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable. At the -same time, larger increments to limits are necessary to avoid blocking if -updates are less frequent, requiring larger resource commitments at the -receiver. There is a trade-off between resource commitment and overhead when -determining how large a limit is advertised. +MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable. On the +other hand, if updates are less frequent, larger increments to limits are +necessary to avoid blocking a sender, requiring larger resource commitments at +the receiver. There is a trade-off between resource commitment and overhead +when determining how large a limit is advertised. A receiver can use an autotuning mechanism to tune the frequency and amount of advertised additional credit based on a round-trip time estimate and the rate at @@ -834,8 +833,8 @@ flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent. When a sender receives credit after being blocked, it can send a large amount of -data in response resulting in short-term congestion; see Section 6.9 in -{{QUIC-RECOVERY}} for a discussion of how a sender could avoid this congestion. +data in response, resulting in short-term congestion; see Section 6.9 in +{{QUIC-RECOVERY}} for a discussion of how a sender can avoid this congestion. ## Handling Stream Cancellation {#stream-cancellation} From 906c77f51c88d60d0de9f98fed0b9591192923ad Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 18 Dec 2019 19:07:15 -0800 Subject: [PATCH 5/6] rephrase and slight shuffle --- draft-ietf-quic-transport.md | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index fb36665b93..6a876edd5c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -801,22 +801,12 @@ limit is increased. ## Flow Credit Increments {#fc-credit} -Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA -and MAX_DATA frames. This section describes one requirement and offers a few -considerations. - -A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before -sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so means that a sender -will be blocked for the rest of the connection if the peer chooses to not send -STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these frames, -waiting for them means that a sender will be blocked for at least an entire -round trip. - -A sender that runs out of flow control credit will be unable to send new data -and is considered blocked, resulting in degraded performance for the -connection. To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or -MAX_DATA frame multiple times within a round trip or send it early enough to -allow for recovery from loss of the frame. +Implementations decide when and how much credit to advertise in MAX_STREAM_DATA +and MAX_DATA frames, but this section offers a few considerations. + +To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or MAX_DATA +frame multiple times within a round trip or send it early enough to allow for +recovery from loss of the frame. Control frames contribute to connection overhead. Therefore, frequently sending MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable. On the @@ -832,6 +822,13 @@ implementations. As an optimization, an endpoint could send frames related to flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent. +A sender that is blocked could choose to not send STREAM_DATA_BLOCKED or +DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a +STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a MAX_STREAM_DATA or +MAX_DATA frame; doing so could result in the sender being blocked for the rest +of the connection. Even if the sender sent these frames, waiting for them will +result in the sender being blocked for at least an entire round trip. + When a sender receives credit after being blocked, it can send a large amount of data in response, resulting in short-term congestion; see Section 6.9 in {{QUIC-RECOVERY}} for a discussion of how a sender can avoid this congestion. From d626db6f961f3e5a48b6e4891ff5fa1af2827fec Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 19 Dec 2019 19:53:45 -0800 Subject: [PATCH 6/6] Ian's suggestions --- draft-ietf-quic-transport.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 6a876edd5c..f7ef27d75a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -822,16 +822,17 @@ implementations. As an optimization, an endpoint could send frames related to flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent. -A sender that is blocked could choose to not send STREAM_DATA_BLOCKED or -DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a -STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a MAX_STREAM_DATA or -MAX_DATA frame; doing so could result in the sender being blocked for the rest -of the connection. Even if the sender sent these frames, waiting for them will -result in the sender being blocked for at least an entire round trip. - -When a sender receives credit after being blocked, it can send a large amount of -data in response, resulting in short-term congestion; see Section 6.9 in -{{QUIC-RECOVERY}} for a discussion of how a sender can avoid this congestion. +A blocked sender is not required to send STREAM_DATA_BLOCKED or DATA_BLOCKED +frames. Therefore, a receiver MUST NOT wait for a STREAM_DATA_BLOCKED or +DATA_BLOCKED frame before sending a MAX_STREAM_DATA or MAX_DATA frame; doing so +could result in the sender being blocked for the rest of the connection. Even if +the sender sends these frames, waiting for them will result in the sender being +blocked for at least an entire round trip. + +When a sender receives credit after being blocked, it might be able to send a +large amount of data in response, resulting in short-term congestion; see +Section 6.9 in {{QUIC-RECOVERY}} for a discussion of how a sender can avoid this +congestion. ## Handling Stream Cancellation {#stream-cancellation}