Re: [quicwg/base-drafts] Stream0 dt output for merge (#1450)

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.

24h warning.

There are a number of things that this text leaves open, and in some cases things are broken (see esp. Retry), but we can't afford to leave this open any longer.  If you have new issues; this isn't the place to discuss them.  It's OK to open a new issue with the assumption that this PR will be merged, because it will be.  (I'll take some of the open comments here and make issues.  It looks like we already have issues for the Retry problems.)

>  
-When the alarm fires, the sender MUST retransmit all unacknowledged handshake
-data, by calling RetransmitAllUnackedHandshakeData(). On each consecutive
-firing of the handshake alarm, the sender SHOULD double the handshake timeout
-and set an alarm for this period.
+When CRYPTO_HS frames are outstanding, the TLP and RTO timers are not active
+unless the CRYPTO_HS frames were sent at 1RTT encryption.

Is this encryption level or packet number space?

Also, the first SHOULD in the previous paragraph needs at least one caveat for this case.

> @@ -422,6 +441,14 @@ sending any ACK frames in response.  In this case they can determine
 whether an immediate or delayed acknowledgement should be generated
 after processing incoming packets.
 
+### Crypto Handshake Data
+
+In order to quickly complete the handshake and avoid spurious
+retransmissions due to handshake alarm timeouts, handshake packets
+SHOULD use a very short ack delay, such as 1ms.  ACK frames MAY be

The MAY is weird.  ACK can always be sent immediately.

>  
+Unlike TLS over TCP, QUIC applications which want to send data do not
+send it through TLS "application_data" records. Rather, they send it
+as QUIC STREAM frames which are then carried in QUIC packets.
+
+
+# Carrying TLS Messages {#carrying-tls}
+
+QUIC carries TLS handshake data in CRYPTO_HS frames, each of which
+consists of a contiguous block of handshake data identified by an
+offset and length. Those frames are packaged into QUIC packets
+and encrypted under the current TLS encryption level.
+As with TLS over TCP, once TLS handshake data has
+been delivered to QUIC, it is QUIC's responsibility to deliver it
+reliably. Each chunk of data is associated with the then-current TLS
+sending keys, and if QUIC needs to retransmit that data, it MUST use

We use "encryption level" rather than sending keys, but I don't think that either works very well for this; TLS has a strict notion of what should be used to protect every octet, but there are multiple of these contexts in flight at the same time.  Needs work.

> +
+- CRYPTO_HS frames MAY appear in packets of any encryption level.
+- CONNECTION_CLOSE and CRYPTO_CLOSE MAY appear in packets of any
+  encryption level other than 0-RTT.
+- PADDING and PING frames MAY appear in packets of any encryption level.
+- ACK frames MAY appear in packets of any encryption level, but
+  MUST only acknowledge packets which appeared in that encryption
+  level.
+- STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels.
+- All other frame types MUST only appear at the 1-RTT levels.
+
+Because packets may be reordered on the wire, QUIC uses the packet
+type to indicate which level a given packet was encrypted
+under, as shown in {{packet-types-levels}}. When multiple packets of
+different encryption levels need to be sent, endpoints SHOULD use
+coalesced packets to send them in the same UDP datagram.

I agree with Christian here.  Nothing says that sending together is necessary, no matter how good it might be for performance.

> -A QUIC server starts the process by providing TLS with stream 0 octets.
-
-Each time that an endpoint receives data on stream 0, it delivers the octets to
-TLS if it is able.  Each time that TLS is provided with new data, new handshake
-octets are requested from TLS.  TLS might not provide any octets if the
-handshake messages it has received are incomplete or it has no data to send.
-
-At the server, when TLS provides handshake octets, it also needs to indicate
-whether the octets contain a HelloRetryRequest.  A HelloRetryRequest MUST always
-be sent in a Retry packet, so the QUIC server needs to know whether the octets
-are a HelloRetryRequest.
+A QUIC server starts the process by providing TLS with the client's
+handshake octets.
+
+At any given time, an endpoint will have a current sending encryption
+level and receiving encryption level. Each encryption level is

I see.  The problem here is that I was thinking QUIC, and this really applies to TLS.  TLS assumes ordering, but QUIC doesn't.  That's something that needs to be improved here, but I don't think that we need to do that here.

> @@ -2849,43 +3014,19 @@ received packets in preference to packets received in the past.
 
 ### ACK Frames and Packet Protection
 
-ACK frames that acknowledge protected packets MUST be carried in a packet that
-has an equivalent or greater level of packet protection.
-
-Packets that are protected with 1-RTT keys MUST be acknowledged in packets that
-are also protected with 1-RTT keys.
-
-A packet that is not protected and claims to acknowledge a packet number that
-was sent with packet protection is not valid.  An unprotected packet that
-carries acknowledgments for protected packets MUST be discarded in its entirety.
+ACK frames MUST only be carried in a packet that has the same packet

My point is that you can't cross-ACK because you aren't capable of acknowledging something in a different packet number space.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1450#pullrequestreview-131038370