Draft: draft-ietf-quic-datagram

Commentary: Defines the transport parameter as a unidirectional configuration . 
 The spec clearly states the following : 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  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 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 principly due to this clause in the present draft : 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 . Having asymmetric values is fine because the paths can be asymmetric and other TPs also behave asymmetrically . The draft also says : 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 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 with
Support for receiving the DATAGRAM frame types is advertised by means
of a QUIC Transport Parameter (name=max_datagram_frame_size,
value=0x0020).  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.  An endpoint that includes this parameter supports the
DATAGRAM frame types and is willing to receive such frames on this
connection.  Endpoints MUST NOT send DATAGRAM frames until they have
sent and received the max_datagram_frame_size transport parameter.
Endpoints MUST NOT send DATAGRAM frames of size strictly larger than
the value of max_datagram_frame_size the endpoint has received from
its peer.  An endpoint that receives a DATAGRAM frame when it has not
sent the max_datagram_frame_size transport parameter MUST terminate
the connection with error PROTOCOL_VIOLATION.  An endpoint that
receives a DATAGRAM frame that is strictly larger than the value it
sent in its max_datagram_frame_size transport parameter MUST
terminate the connection with error PROTOCOL_VIOLATION.  Endpoints
that wish to use DATAGRAM frames need to ensure they send a
max_datagram_frame_size value sufficient to allow their peer to use
them.  It is RECOMMENDED to send the value 65536 in the
max_datagram_frame_size transport parameter as that indicates to the
peer that this endpoint will accept any DATAGRAM frame that fits
inside a QUIC packet.
Support for receiving the DATAGRAM frame types is advertised by means
of a QUIC Transport Parameter (name=max_datagram_frame_size,
value=0x0020).  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.  An endpoint that includes this parameter supports the
DATAGRAM frame types and is willing to receive such frames on this
connection.  Endpoints MUST NOT send DATAGRAM frames until they have
received the max_datagram_frame_size transport parameter.  Endpoints
MUST NOT send DATAGRAM frames of size strictly larger than the value
of max_datagram_frame_size the endpoint has received from its peer.
An endpoint that receives a DATAGRAM frame when it has not sent the
max_datagram_frame_size transport parameter MUST terminate the
connection with error PROTOCOL_VIOLATION.  An endpoint that receives
a DATAGRAM frame that is strictly larger than the value it sent in
its max_datagram_frame_size transport parameter MUST terminate the
connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use
DATAGRAM frames need to ensure they send a max_datagram_frame_size
value sufficient to allow their peer to use them.  It is RECOMMENDED
to send the value 65536 in the max_datagram_frame_size transport
parameter as that indicates to the peer that this endpoint will
accept any DATAGRAM frame that fits inside a QUIC packet.
The max_datagram_frame_size transport parameter is a unidirectional
limit and indication of support of DATAGRAM frames.  Application
protocols that use DATAGRAM frames MAY choose to only negotiate and
use them in a single direction.