From 7f0dd505ab37f4b44271c15edb52c32abd0d73a7 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Sat, 3 Nov 2018 13:22:25 +0700 Subject: [PATCH] s/SHOULD/MUST --- draft-ietf-quic-transport.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2d7d7ebfe7..cb8770bef9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -778,8 +778,6 @@ 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. - - 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 @@ -859,7 +857,7 @@ number of streams available to peers roughly consistent. An endpoint that is unable to open a new stream due to the peer's limits SHOULD send a STREAMS_BLOCKED frame ({{frame-streams-blocked}}). This signal is -considered useful for debugging. An endpoint SHOULD NOT wait to receive this +considered useful for debugging. An endpoint MUST NOT wait to receive this signal before advertising additional credit, since doing so will mean that the peer will be blocked for at least an entire round trip, and potentially for longer if the peer chooses to not send STREAMS_BLOCKED frames.