Change:
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 <del> 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 13 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. Similarly, an appliaction has usually no control about the length of a QUIC packet on the wire.  However, QUIC provides the ability to add a padding frame to impact the packet size.  This is mainly used by QUIC itself in the first packet in order to ensure that the path is capable of transferring packets of at least a certain size. Additionally, a QUIC implementation can expose an application layer interface to specify a certain packet size.  This can either be used by the application to force certian packet sizes in specific use cases/networks, or ensure that all packets are equally sized to conceal potential leakage of application layer information when the data sent by the application are not greedy.  Note the initial packet must have a minimum size of 1200 bytes according to the QUIC specification.  A receiver of a smaller initial packet may reject this packet in order to avoid amplification attacks. </del> <ins> are bundled into packets. By default, many QUIC implementations will try to maximally pack packets with one or more stream data frames to minimize bandwidth consumption and computational costs (see section 13 of QUIC).  If there is not enough data available to fill a packet, an implementation might 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. Similarly, an application has usually no control about the length of a QUIC packet on the wire.  QUIC provides the ability to add a PADDING frame to arbitrarily increase the size of packets. Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, both during the handshake and for connection migration.  Padding can also be used by an application to reduce leakage of information about the data that is sent.  A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding. </ins> 6.

Discussion:
Quite a few pieces of text in here that needed corrections. As before, I'm happy to pull out individual commits so we can discuss.