Rationalize stream 0 flow control

This leaves the exemption to the stream-level flow control for Initial and
Retry packets only (previously it was Initial only).  But, to address the
possibility that the flow control limit is too small for the entire handshake
it permits the sending of MAX_STREAM_DATA (and STREAM_BLOCKED) during the
handshake.

Closes #1074, #725, #1082.

draft-ietf-quic-tls.md

@@ -1269,20 +1269,12 @@ both protected with 1-RTT keys and contains an `ACK` frame.
 
 ### Updates to Data and Stream Limits
 
-`MAX_DATA`, `MAX_STREAM_DATA`, `BLOCKED`, `STREAM_BLOCKED`, and `MAX_STREAM_ID`
-frames MUST NOT be sent unprotected.
+`MAX_DATA`, `BLOCKED`, `MAX_STREAM_ID`, and `STREAM_ID_BLOCKED` frames MUST NOT
+be sent unprotected.
 
-Though data is exchanged on stream 0, the initial flow control window on that
-stream is sufficiently large to allow the TLS handshake to complete.  This
-limits the maximum size of the TLS handshake and would prevent a server or
-client from using an abnormally large certificate chain.
-
-Stream 0 is exempt from the connection-level flow control window.
-
-Consequently, there is no need to signal being blocked on flow control.
-
-Similarly, there is no need to increase the number of allowed streams until the
-handshake completes.
+`MAX_STREAM_DATA` and `STREAM_BLOCKED` frames MUST NOT be sent unprotected
+unless they identify stream 0.  Stream 0 is exempt from the connection-level
+flow control window and stream limits.
 
 
 ### Handshake Failures

draft-ietf-quic-transport.md

@@ -2825,7 +2825,6 @@ actually lost.
 
 ### Special Considerations for Packetization Layer PMTU Discovery
 
-
 The PADDING frame provides a useful option for PMTU probe packets that does not
 exist in other transports. PADDING frames generate acknowledgements, but their
 content need not be delivered reliably. PADDING frames may delay the delivery of
@@ -3251,6 +3250,7 @@ advertise a smaller maximum ID.  A sender may receive MAX_STREAM_ID frames out
 of order; a sender MUST therefore ignore any MAX_STREAM_ID that does not
 increase the maximum.
 
+
 ## Sending and Receiving Data
 
 Once a stream is created, endpoints may use the stream to send and receive data.
@@ -3270,14 +3270,25 @@ delivery, as long as it is not in violation of the receiver's flow control
 limits.
 
 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,
-is exempt from the connection-level data limits established by MAX_DATA. Data on
-stream 0 other than the initial cryptographic handshake message is still subject
-to stream-level data limits and MAX_STREAM_DATA. This message is exempt
-from flow control because it needs to be sent in a single packet regardless of
-the server's flow control state. This rule applies even for 0-RTT handshakes
-where the remembered value of MAX_STREAM_DATA would not permit sending a full
-initial cryptographic handshake message.
+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.  That is, data sent on
+stream 0 is not counted against the limit expressed by MAX_DATA.  Data on stream
+0 is still subject to stream-level data limits and MAX_STREAM_DATA.
+
+Data sent in the Initial and Retry packets do not count toward stream 0 flow
+control limits.  These packet types do not permit the sending of data in
+multiple packets, so there is no opportunity for a peer to send MAX_STREAM_DATA
+frames.  Note also that the next packet sent after either of these packets might
+start at a stream offset of 0.  Thus, the only limit on the size of the
+cryptographic handshake messages these packets contain is determined by the MTU.
+
+Endpoints MUST respect the stream flow control limit set by their peer.  A
+client might exceed this limit when sending an Initial packet and so might need
+to await a MAX_STREAM_DATA frame from the server before it can sent additional
+STREAM frames.  A client MAY send ACK frames and STREAM_BLOCKED frames for
+stream 0.
 
 Flow control is described in detail in {{flow-control}}, and congestion control
 is described in the companion document {{QUIC-RECOVERY}}.