Session Establishment sequence and timeouts

[TimEvens]

Section 3.3 and 6.2 do not clearly identify that CLIENT_SETUP is the first message over the control stream, sent by the client, and that the server will wait till that arrives so that it can respond to it via a SERVER_SETUP. In section 6.2.1 under versions, it does indicate that the server responds to the client supported version list with a selected "client" version, which means that SERVER_SETUP is a response message to a CLIENT_SETUP.

For example...

sequenceDiagram
    participant client
    participant server
client ->>+server:QUIC connection
server -->>-client:QUIC established 
client ->>+server:Create bi-dir stream
client ->>server:CLIENT_SETUP
server -->>-client:SERVER_SETUP

How long should/must the server wait for the CLIENT_SETUP message? QUIC level keep alives will keep the connection alive and the server will be stuck in lingering state for a CLIENT_SETUP message. The client should also have some expected wait time for a SERVER_SETUP response message.

[afrind]

Individual Comment:

I don't think the draft should specify explicit timeouts for the peer to send a message, each implementation or application will define its own reasonable limits. Perhaps we could mention the usefulness of timeouts in general in the security section?

[TimEvens]

@afrind , At a minimum, yes... update the security section with the need to have timeouts because the lack of timeout enables DoS exploits.

Regarding what the draft should indicate in terms of timeout... I believe timeouts will be implemented by every production implementation of MOQT relay. Clients may get away without implementing a timeout ,but likely every production client will also have a timeout. Negotiating this timeout, such as via a CLIENT_SETUP/SERVER_SETUP would help to avoid error recovery responses to fast reconnect only to result in the same situation. IMO, the MOQT draft MUST at minimum define a new termination reason code (Section 3.5) for the following:

• Receive Control Message Timeout - Timeout while processing the control message
• Receive Object Header Timeout - Timeout while receiving the object datagram header, stream per object header, stream per track header, stream per group header, and the object data header in the case of stream per group or track.
• Received Object Payload Timeout - Timeout specifically relating to receiving the payload data per the object payload length