Draft: draft-ietf-quic-tls

Commentary: This PR restructures 17.3 to be aligned with 17.2 . Note that while the diff seems to show whole paragraphs changed in the section , all I 've done is replaced with . Note that I 've not replaced all uses of . I 've retained it where it is used alongside , for symmetry . This still touches more text than I had hoped , but it makes the structure of Section 17 clearer . 
 Thanks for the note . I 've updated the tls doc , but I 've left most uses of as they are . I 've retained them for symmetry , since in all the ones I 've retained , it appears alongside . 
 While the transport draft talks a lot about " 1 - RTT packets " , the term is not defined . We also have a sentence that seem to imply that a long - header variant of 1 - RTT packets might exist ( ) . We refer to the packet less frequently as " short header packets " or " packet with a short header . " As a resolution , I think we might want to change the title of section 17.3 from " Short Header Packets " to " 1 - RTT Packets " . Rest of the text can remain the same , as the first sentence of that section says that it is the only type of short header packet that we define . 
 Update : I think we might want to make corresponding changes to the TLS draft . Re TLS draft , I think we can replace all the occurrences of " short header packet(s ) " , " packet(s ) with ( a ) short header " in the TLS draft with " 1 - RTT packet(s ) " , as well making necessary changes to table 1.This looks good . The actual changes are much smaller than the diff appears , and I think the symmetry with 17.2 helps readability despite the extra layer .
Paragraph (version A):
fig-sample shows an example long header packet (Initial) and a short
header packet. fig-sample shows the fields in each header that are
covered by header protection and the portion of the protected packet
payload that is sampled.
Paragraph (version B):
fig-sample shows an example long header packet (Initial) and a short
header packet (1-RTT). fig-sample shows the fields in each header
that are covered by header protection and the portion of the
protected packet payload that is sampled.
Paragraph (version A):
Multiple QUIC packets - even of different packet types - can be
coalesced into a single UDP datagram; see packet-coalesce.  As a
result, this handshake could consist of as few as 4 UDP datagrams, or
any number more (subject to limits inherent to the protocol, such as
congestion control and anti-amplification).  For instance, the
server's first flight contains Initial packets, Handshake packets,
and "0.5-RTT data" in 1-RTT packets with a short header.
Paragraph (version B):
Multiple QUIC packets - even of different packet types - can be
coalesced into a single UDP datagram; see packet-coalesce.  As a
result, this handshake could consist of as few as 4 UDP datagrams, or
any number more (subject to limits inherent to the protocol, such as
congestion control and anti-amplification).  For instance, the
server's first flight contains Initial packets, Handshake packets,
and "0.5-RTT data" in 1-RTT packets.
Paragraph (version A):
Application data space: All 0-RTT (packet-0rtt) and 1-RTT (short-
header) encrypted packets are in this space.
Paragraph (version B):
Application data space: All 0-RTT (packet-0rtt) and 1-RTT (packet-
1rtt) encrypted packets are in this space.
Paragraph (version B):
A 1-RTT packet uses a short packet header.  It is used after the
version and 1-RTT keys are negotiated.
Paragraph (version A):
Packets with a short header always include a 1-RTT protected
payload.
Paragraph (version A):
The latency spin bit enables passive latency monitoring from
observation points on the network path throughout the duration of a
connection.  The server reflects the spin value received, while the
client 'spins' it after one RTT.  On-path observers can measure the
time between two spin bit toggle events to estimate the end-to-end
RTT of a connection.
Paragraph (version A):
The spin bit is only present in the short packet header, since it is
possible to measure the initial RTT of a connection by observing the
handshake.  Therefore, the spin bit is available after version
negotiation and connection establishment are completed.  On-path
measurement and use of the latency spin bit is further discussed in
QUIC-MANAGEABILITY.
Paragraph (version A):
The spin bit is an OPTIONAL feature of QUIC.  A QUIC stack that
chooses to support the spin bit MUST implement it as specified in
this section.
Paragraph (version B):
1-RTT packets always include a 1-RTT protected payload.
Paragraph (version B):
The latency spin bit, which is defined for 1-RTT packets (packet-
1rtt), enables passive latency monitoring from observation points on
the network path throughout the duration of a connection.  The server
reflects the spin value received, while the client 'spins' it after
one RTT.  On-path observers can measure the time between two spin bit
toggle events to estimate the end-to-end RTT of a connection.
Paragraph (version B):
The spin bit is only present in 1-RTT packets, since it is possible
to measure the initial RTT of a connection by observing the
handshake.  Therefore, the spin bit is available after version
negotiation and connection establishment are completed.  On-path
measurement and use of the latency spin bit is further discussed in
QUIC-MANAGEABILITY.
Paragraph (version B):
The spin bit is an OPTIONAL feature of this version of QUIC.  A QUIC
stack that chooses to support the spin bit MUST implement it as
specified in this section.
Paragraph (version A):
If the spin bit is enabled for the connection, the endpoint maintains
a spin value for each network path and sets the spin bit in the short
header to the currently stored value when a packet with a short
header is sent on that path.  The spin value is initialized to 0 in
the endpoint for each network path.  Each endpoint also remembers the
highest packet number seen from its peer on each path.
Paragraph (version A):
When a server receives a short header packet that increases the
highest packet number seen by the server from the client on a given
network path, it sets the spin value for that path to be equal to the
spin bit in the received packet.
Paragraph (version A):
When a client receives a short header packet that increases the
highest packet number seen by the client from the server on a given
network path, it sets the spin value for that path to the inverse of
the spin bit in the received packet.
Paragraph (version B):
If the spin bit is enabled for the connection, the endpoint maintains
a spin value for each network path and sets the spin bit in the
packet header to the currently stored value when a 1-RTT packet is
sent on that path.  The spin value is initialized to 0 in the
endpoint for each network path.  Each endpoint also remembers the
highest packet number seen from its peer on each path.
Paragraph (version B):
When a server receives a 1-RTT packet that increases the highest
packet number seen by the server from the client on a given network
path, it sets the spin value for that path to be equal to the spin
bit in the received packet.
Paragraph (version B):
When a client receives a 1-RTT packet that increases the highest
packet number seen by the client from the server on a given network
path, it sets the spin value for that path to the inverse of the spin
bit in the received packet.