Draft: draft-ietf-quic-applicability

Commentary: A pass of clarity / grammar nits in applicability draft after reading through
Paragraph (version A):
provide the respective credentials), the cost for establishing
another connection are extremely low.
Paragraph (version A):
Quic provides an interface that provides multiple streams to the
application, however, the application usually doesn't have control
how the data transmitted over one stream is mapped into frame and how
frames are bundled into packets.  By default QUIC will try to
maximally pack packets to minimize bandwidth consumption and
computational costs with one or multiple same data frames.  If not
enough data available to send QUIC may even wait for a short time,
trading of latency and bandwidth efficiency.  This time might either
be pre-configured or can the dynamically adjusted based on the
observed sending pattern of the application.  If the application
requires low latency, with only small chunks of data to send, it may
be valuable to indicate to QUIC that all data should be send out
immediately.  Or if a certain sending pattern is know by the
application, it might also provide valuable guidance to QUIC how long
it should wait to bundle frame into a packet.
Paragraph (version A):
Stream prioritization is not exposed to the network, nor to the
receiver.  Prioritization can be realized by the sender and the QUIC
transport should provide an interface for applications to prioritize
streams QUIC.  Further applications can implement their own
prioritization scheme on top of QUIC: (an application) protocol that
runs on top of QUIC can define explicit messages for signaling
priority, such as those defined for HTTP/2; it can define rules that
allow an endpoint to determine priority based on context; or it can
provide a higher level interface and leave the determination to the
application on top.
Paragraph (version B):
provide the respective credentials), the cost of establishing another
connection is extremely low.
Paragraph (version B):
QUIC provides an interface that provides multiple streams to the
application; however, the application usually cannot control how data
transmitted over one stream is mapped into frames or how those frames
are bundled into packets.  By default, QUIC will try to maximally
pack packets with one or more stream data frames to minimize
bandwidth consumption and computational costs.  If there is not
enough data available to fill a packet, QUIC may even wait for a
short time, to optimize bandwidth efficiency instead of latency.
This delay can either be pre-configured or dynamically adjusted based
on the observed sending pattern of the application.  If the
application requires low latency, with only small chunks of data to
send, it may be valuable to indicate to QUIC that all data should be
send out immediately.  Alternatively, if the application expects to
use a specific sending pattern, it can also provide a suggested delay
to QUIC for how long to wait before bundle frames into a packet.
Paragraph (version B):
Stream prioritization is not exposed to either the network or the
receiver.  Prioritization is managed by the sender, and the QUIC
transport should provide an interface for applications to prioritize
streams QUIC.  Further applications can implement their own
prioritization scheme on top of QUIC: an application protocol that
runs on top of QUIC can define explicit messages for signaling
priority, such as those defined for HTTP/2; it can define rules that
allow an endpoint to determine priority based on context; or it can
provide a higher level interface and leave the determination to the
application on top.
Paragraph (version A):
Priority handling of retransmissions can be implemented by the sender
in the transport layer.  QUIC recommends to retransmit lost data
before new data, unless indicated differently by the application.
Currently QUIC only provides fully reliable stream transmission, and
as such prioritization of retransmissions likely beneficial in most
cases, as gaps that get filled up and thereby free up flow control.
For not fully reliable streams priority scheduling of retransmissions
over data of higher-priority streams might not be desired.  In this
case QUIC could also provide an interface or derive the
prioritization decision from the reliability level of the stream.
Paragraph (version B):
Priority handling of retransmissions can be implemented by the sender
in the transport layer.  QUIC recommends to retransmit lost data
before new data, unless indicated differently by the application.
Currently, QUIC only provides fully reliable stream transmission,
which means that prioritization of retransmissions will be beneficial
in most cases, by filling in gaps and freeing up the flow control
window.  For partially reliable or unreliable streams, priority
scheduling of retransmissions over data of higher-priority streams
might not be desirable.  For such streams, QUIC could either provide
an explicit interface to control prioritization, or derive the
prioritization decision from the reliability level of the stream.
Paragraph (version A):
QUIC exposes some information to the network in the unencrypted part
of the header, either before the encryption context is established,
because the information is intended to be used by the network.  QUIC
has a long header that is used during connection establishment and
for other control processes, and a short header that may be used for
data transmission in an established connection.  While the long
header is fixed and exposes some information, the short header only
exposes the packet number by default and may optionally expose a
connection ID.
Paragraph (version B):
QUIC exposes some information to the network in the unencrypted part
of the header, either before the encryption context is established,
because the information is intended to be used by the network.  QUIC
has a long header that is used during connection establishment and
for other control processes, and a short header that may be used for
data transmission in an established connection.  While the long
header always exposes some information (such as the version and
Connection IDs), the short header only optionally exposes a single
Connection ID.
Paragraph (version A):
QUIC provides a Server Retry packet that can be sent by a server in
response to the Client Initial packet.  The server may choose a new
connection ID in that packet and the client will retry by sending
another Client Initial packet with the server-selected connection ID.
This mechanism can be used to redirect a connection to a different
server, e.g. due to performance reasons or when servers in a server
pool are upgraded gradually, and therefore may support different
versions of QUIC.  In this case, it is assumed that all servers
belonging to a certain pool are served in cooperation with load
balancers that forward the traffic based on the connection ID.  A
server can chose the connection ID in the Server Retry packet such
that the load balancer will redirect the next Client Initial packet
to a different server in that pool.
Paragraph (version B):
QUIC provides a Server Retry packet that can be sent by a server in
response to the Client Initial packet.  The server may choose a new
Connection ID in that packet and the client will retry by sending
another Client Initial packet with the server-selected Connection ID.
This mechanism can be used to redirect a connection to a different
server, e.g. due to performance reasons or when servers in a server
pool are upgraded gradually, and therefore may support different
versions of QUIC.  In this case, it is assumed that all servers
belonging to a certain pool are served in cooperation with load
balancers that forward the traffic based on the Connection ID.  A
server can choose the Connection ID in the Server Retry packet such
that the load balancer will redirect the next Client Initial packet
to a different server in that pool.
Paragraph (version A):
Versioning in QUIC may change the protocol's behavior completely,
except for the meaning of a few header fields that have been declared
to be fixed.  As such version of QUIC with a higher version number
does not necessarily provide a better service, but might simply
provide a very different service, so an application needs to be able
to select which versions of QUIC it wants to use.
Paragraph (version B):
Versioning in QUIC may change the protocol's behavior completely,
except for the meaning of a few header fields that have been declared
to be invariant QUIC-INVARIANTS.  A version of QUIC with a higher
version number will not necessarily provide a better service, but
might simply provide a different feature set.  As such, an
application needs to be able to select which versions of QUIC it
wants to use.