Draft: draft-ietf-quic-applicability

Commentary: Also addresses 
 addressed by PR 
 lgtm
Paragraph (version A):
QUIC provides for 0-RTT connection establishment (see section 3.2 of
QUIC).  This presents opportunities and challenges for applications
using QUIC.
Paragraph (version B):
QUIC provides for 0-RTT connection establishment.  This presents
opportunities and challenges for applications using QUIC.
Paragraph (version A):
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):
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 (see section 8 of
QUIC).  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 A):
QUIC supports a server-generated Connection ID, transmitted to the
client during connection establishment: see Section 5.7 of QUIC.
Servers behind load balancers should propose a Connection ID during
the handshake, encoding the identity of the server or information
about its load balancing pool, in order to support stateless load
balancing.  Once the server generates a Connection ID that encodes
its identity, every CDN load balancer would be able to forward the
packets to that server without needing information about every
specific flow it is forwarding.
Paragraph (version B):
QUIC supports a server-generated Connection ID, transmitted to the
client during connection establishment (see Section 6.1 of QUIC).
Servers behind load balancers should propose a Connection ID during
the handshake, encoding the identity of the server or information
about its load balancing pool, in order to support stateless load
balancing.  Once the server generates a Connection ID that encodes
its identity, every CDN load balancer would be able to forward the
packets to that server without needing information about every
specific flow it is forwarding.