Draft: draft-ietf-quic-applicability

Commentary: One sentences to address remaining bits for 
 I did n'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 does n't like this but can fix after it lands .
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.