Original text:
Mapping of application data to streams is application-specific and described for HTTP/s in QUIC-HTTP.  In general data that can be processed independently, and therefore would suffer from head of line <del> blocking, if forced to be received in order, should be transmitted over different streams.  If there is a logical grouping of those data chunks or messages, stream can be reused, or a new stream can be opened for each chunk/message.  If one message is mapped on a single stream, resetting the stream if the message is not needed anymore can be used to emulate partialreliability on a message basis.  If a QUIC receiver has maximum allowed concurrent streams open and the sender on the other end indicates that more streams are needed, it doesn't automatically lead to an increase of the maximum number of streams by the receiver.  Therefore it can be valuable to expose maximum number of allowed, currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. </del>  Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually

Reviewer comments:
One sentences added to address remaining bits for
NAME I didn't replace "five-tuple" with "connection" in this sentence in this PR: "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 five-tuple. " because it already has connection in the sentence; so we could only remove the last half sentence, but I actually think there is a value in leaving this in because some application may actually care about the 5-tuple.
WFM. We should probably do an editorial pass to make sure we're using terms like "5-tuple" and "connection" and "path" properly everywhere anyway.
See also section on Streams in transport draft: "Stream offsets allow for the octets on a stream to be placed in order. An endpoint MUST be capable of delivering data received on a stream in order. Implementations MAY choose to offer the ability to deliver data out of order. There is no means of ensuring ordering between octets on different streams."
See PR
lgtm modulo editorial. circleci doesn't like this but can fix after it lands.

Revised text:
Mapping of application data to streams is application-specific and described for HTTP/s in QUIC-HTTP.  In general data that can be processed independently, and therefore would suffer from head of line  <ins> blocking if forced to be received in order, should be transmitted over different streams.  If the application requires certain data to be received in order, the same stream should be used for that data. 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 expire an unacknowledged message can be used to emulate partial reliability on a message basis.  If a QUIC receiver has maximum allowed concurrent streams open and the sender on the other end indicates that more streams are needed, it doesn't automatically lead to an increase of the maximum number of streams by the receiver. Therefore it can be valuable to expose maximum number of allowed, currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. </ins> Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually