Code change:
QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line blocking between streams, associated at a point in time with a single <del> five-tuple.  Stream data is carried within Frames, where one (UDP) packet on the wire can carry one of multiple stream frames. Stream can be independently open and closed, gracefully or by error. If a critical stream for the application is closed, the application can generate respective error messages on the application layer to inform the other end or the higher layer and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface to exceptional handling of any stream.  There are special streams in QUIC that are used for control on the QUIC connection, however, these streams are not exposed to the application. </del> <ins> five-tuple.  Stream data is carried within Frames, where one QUIC packet on the wire can carry one or multiple stream frames. Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a unidirectional stream can send data on it.  Due to offset encoding limitations, a stream can carry a maximum of 2^62-1 bytes in each direction.  In the presently unlikely event that this limit is reached by an application, the stream can simply be closed and replaced with a new one. Streams can be independently opened and closed, gracefully or by error.  An application can gracefully close the egress direction of a stream by instructing QUIC to send a FIN bit in a STREAM frame.  It cannot gracefully close the ingress direction without a peer- generated FIN, much like in TCP.  However, an endpoint can abruptly close either the ingress or egress direction; these actions are fully independent of each other. If a stream that is critical for an application is closed, the application can generate respective error messages on the application layer to inform the other end and/or the higher layer, and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface for exceptional handling of any stream. </ins> Mapping of application data to streams is application-specific and <del> described for HTTP/s in QUIC-HTTP.  In general data that can be </del> <ins> described for HTTP/3 in QUIC-HTTP.  In general, data that can be </ins> processed independently, and therefore would suffer from head of line blocking if forced to be received in order, should be transmitted <del> over different streams.  If the application requires certain data to be received in order, the same stream should be used for that data. </del> <ins> over separate streams.  If the application requires certain data to be received in order, that data should be sent on the same stream. </ins> If there is a logical grouping of data chunks or messages, streams can be reused, or a new stream can be opened for each chunk/message. If one message is mapped to a single stream, resetting the stream to

Related discussion:
text: This document should mention unidirectional streams Some words about the meaning of an abort signal vs. a clean close would be useful, both ingress and egress. Maximum stream bytes = 2^62-1. Saying "there are special streams for QUIC" is inaccurate (it's just one stream now, conceptually), and I would not bother to describe the CRYPTO frames this way.
Also: stream aborts are always unidirectional. what can/should applications assume about stream IDs? are they accessible, and does the app have any control over them?