quicwg/datagram

Is max_datagram_frame_size Unidirectional Configuration?

Closed this issue · 2 comments

The spec clearly states the following:

The max_datagram_frame_size transport parameter is an integer value (represented as a variable-length integer) that represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) the endpoint is willing to receive, in bytes.

But it's not completely clear what happens if both sides send different values. Is the value purely a unidirectional configuration? For instance, if the server advertises a value of 500, and the client advertises a value of 100, can the client still send 500 byte datagrams? Or does this essentially negotiate the max value either side can use to 100?

If this is a unidirectional configuration, why require the peer to send the TP at all, if all they want to do is send datagrams, and not receive them? I'm loosely basing my thoughts on what the design could be on how we negotiate the number of streams an endpoint is willing to accept. Following that model, I'd recommend a design where, if an endpoint is willing to receive datagrams, it advertises a max_datagram_frame_size it's willing to accept. The TP has absolutely no meaning for the send direction. The protocol on top of QUIC decides how to interpret only a single direction allowing datagrams to be sent.

I agree with @nibanks, principly due to this clause in the present draft:

Endpoints MUST NOT send DATAGRAM frames until they have sent and received the max_datagram_frame_size transport parameter.

My read of the current text is that it is unidirectional. An endpoint tells it's peer that it is willing to receive a DATAGRAM up to size N by using max_datagram_frame_size. Having asymmetric values is fine because the paths can be asymmetric and other TPs also behave asymmetrically.

The draft also says:

Application protocols that use datagrams MUST define how they react to the max_datagram_frame_size transport parameter being missing.

For an application protocol like siduck, both ends need to support reception of DATAGRAM or else the application will fail. For something like an IoT sensor feed, it might be fine to support a send-only/receive-only model. The current text basically requires the application protocol to mandate that max_datagram_frame_size is 0 on the side that is send-only AND to describe what happens if the TP is missing - that seems like it will cause a duplication of effort.

I agree that we should make this purely unidirectional. I would resolve this by replacing

Endpoints MUST NOT send DATAGRAM frames until they have sent and received the max_datagram_frame_size transport parameter.

with

Endpoints MUST NOT send DATAGRAM frames until they have received the max_datagram_frame_size transport parameter.