Code change:
Authenticated and encrypted header and payload <del> QUIC uses UDP as a substrate to avoid requiring changes to legacy client operating systems and middleboxes.  QUIC authenticates all of its headers and encrypts most of the data it exchanges, including its signaling, to avoid incurring a dependency on middleboxes. </del> <ins> QUIC establishes a connection, which is a stateful interaction between a client and server.  The primary purpose of a connection is to support the structured exchange of data by an application protocol. Streams are means by which an application protocol exchanges information.  Streams are ordered sequences of bytes.  Two types of stream can be created: bidirectional streams, which allow both endpoints to send data; and unidirectional streams, which allow a single endpoint to send.  A credit-based scheme is used to limit stream creation and to bound the amount of data that can be sent. The QUIC handshake combines negotiation of cryptographic and transport parameters.  The handshake is structured to permit the exchange of application data as soon as possible.  This includes an option for clients to send data immediately (0-RTT), which might require prior communication to enable. QUIC connections are not strictly bound to a single network path. Connection migration uses connection identifiers to allow connections to transfer to a new network path. Frames are used in QUIC to communicate between endpoints.  One or more frames are assembled into packets.  QUIC authenticates all packets and encrypts as much as is practical.  QUIC packets are carried in UDP datagrams to better facilitate deployment in existing systems and networks. Once established, multiple options are provided for connection termination.  Applications can manage a graceful shutdown, endpoints can negotiate a timeout period, errors can cause immediate connection teardown, and a stateless mechanism provides for termination of connections after one endpoint has lost state. </ins> 1.1.

Related discussion:
text: This does a little shuffling to move some of the context-setting up. It then adds some more meat to the introductory section.
Thanks for the review Jana. I've taken most of this, with small tweaks only. Two things I didn't take: Interleaving explanation with references to sections sounded appealing, but it turns out to be both harder to read as the links break up the flow, and harder to scan for links (the structure section serves as an abbreviated and accessible ToC). I didn't move the connection piece below streams as I think that - at this level - talking about the connection is important context. I've moved the picture to the section, which didn't have that simple diagram (just some more complex ones), and I think benefits from it.
When I was reading quic-transport I found it very difficult to deal with the forward references. Streams are presented before connections, the overall state machine isn't introduced up front, packets come long after frames, and both are long before the wire formats are described. It might worth revisiting the section ordering.
At some point, transport was hugely restructured, and I believe many of those changes were good, but some didn't work out that well. I find streams coming before connections particularly odd.
The larger idea is "high-level concepts, then wire encoding" which I think makes sense. It puts the things that someone needs for a conceptual understanding of the protocol in one place, and the things that someone needs to implement the protocol elsewhere. Within the high-level concepts, I also find it strange that connections don't come before streams. However, the "connections" group also includes things that really don't deserve pride-of-place as the first couple things to be discussed, either.
I think that the main concept you need is that QUIC has a connection that is shared state between two endpoints. The later sections about connections go into more detail than you need to understand the stream sections. But I note that we don't properly provide that basic knowledge in our introductory parts, which are quite lean. Leanness is good, but we might have overdone it slightly in this regard.
Having worked my way through the spec, my suggested resolution to this is that Section 5.3 needs to be earlier, perhaps much earlier. At the least, it should open Section 5; some or all of it might belong in Section 1.
Thanks for working through this!