Clarify 0-RTT handling

[mirjak]

Section 3 says:
“An endpoint MUST NOT send DATAGRAM frames until it has received the max_datagram_frame_size transport parameter with a non-zero value.”

I guess you assume that having received max_datagram_frame_size in a previous connection, when 0-RTT is used, counts but interpreting this MUST strictly, you cannot send datagrams in 0-RTT. Maybe that can be clarified.

Also if datagrams are used with 0-RTT but for some reason are not supported by the server anymore, it would actually be useful to have a more specific error message if the connection is closed by the server.

[DavidSchinazi]

Section 3 says: “An endpoint MUST NOT send DATAGRAM frames until it has received the max_datagram_frame_size transport parameter with a non-zero value.”

I guess you assume that having received max_datagram_frame_size in a previous connection, when 0-RTT is used, counts but interpreting this MUST strictly, you cannot send datagrams in 0-RTT. Maybe that can be clarified.

This is already discussed in Section 3:

   When clients use 0-RTT, they MAY store the value of the server's
   max_datagram_frame_size transport parameter.  Doing so allows the
   client to send DATAGRAM frames in 0-RTT packets.  When servers decide
   to accept 0-RTT data, they MUST send a max_datagram_frame_size
   transport parameter greater or equal to the value they sent to the
   client in the connection where they sent them the NewSessionTicket
   message.  If a client stores the value of the max_datagram_frame_size
   transport parameter with their 0-RTT state, they MUST validate that
   the new value of the max_datagram_frame_size transport parameter sent
   by the server in the handshake is greater or equal to the stored
   value; if not, the client MUST terminate the connection with error
   PROTOCOL_VIOLATION.

Also if datagrams are used with 0-RTT but for some reason are not supported by the server anymore, it would actually be useful to have a more specific error message if the connection is closed by the server.

That's not how 0-RTT works in QUIC. If the server wishes to no longer support datagrams, it MUST reject 0-RTT data and therefore it won't see those DATAGRAM frames.

[tfpauly]

@mirjak given David's explanation, are we OK to close this one?

[mirjak]

I know that this is explained in section 3, but what I'm saying is that the MUST NOT in the text I cited contradicts this text (if you interpret the MUST NOT strictly but maybe I'm to strict here). So to be more clear one could say:

"... MUST NOT send DATAGRAM frames until it has received the max_datagram_frame_size transport parameter with a non-zero value in the handshake, or a previous handshake if 0-RTT is used."

Regarding the server not supporting datagram in 0-RTT anymore, my assumption was that if the server does not have any state if datagram was used but does not support datagram anymore for some reason, it would receive a 0-RTT with a datagram and probably close the connection based on this text:

"An endpoint that receives a DATAGRAM frame when it has not indicated support via the transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION."

I guess you are saying if 0-RTT and datagram is used the server MUST remember that datagram was negotiated?

However, there is also this text:

"If a client stores the value of the max_datagram_frame_size transport parameter with their 0-RTT state, they MUST validate that the new value of the max_datagram_frame_size transport parameter sent by the server in the handshake is greater or equal to the stored value; if not, the client MUST terminate the connection with error PROTOCOL_VIOLATION."

So this would mean larger datagram are accepted in 0-RTT but then if the server indicates a smaller value for 1-RTT, the connection needs to be terminated? Why?

Also if datagram was used in the previous connection, then 0-RTT is used without datagrams, the server can still not indicate in the handshake that is not supporting datagram anymore?

All I'm saying is that these things could be further clarified to avoid any doubt.

[DavidSchinazi]

I know that this is explained in section 3, but what I'm saying is that the MUST NOT in the text I cited contradicts this text (if you interpret the MUST NOT strictly but maybe I'm to strict here). So to be more clear one could say:

"... MUST NOT send DATAGRAM frames until it has received the max_datagram_frame_size transport parameter with a non-zero value in the handshake, or a previous handshake if 0-RTT is used."

Adding "or a previous handshake if 0-RTT is used" is fine by me.

Regarding the server not supporting datagram in 0-RTT anymore, my assumption was that if the server does not have any state if datagram was used but does not support datagram anymore for some reason, it would receive a 0-RTT with a datagram

Your assumption is incorrect. If servers used to support datagram and they accept 0-RTT, they must also support datagram in the new connection. That's spelled out here:

   When servers decide
   to accept 0-RTT data, they MUST send a max_datagram_frame_size
   transport parameter greater or equal to the value they sent to the
   client in the connection where they sent them the NewSessionTicket
   message.

All I'm saying is that these things could be further clarified to avoid any doubt.

Clarifications are always good. Can you send a PR?