This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review.

Thank you for a clearly written draft. From a transport perspective the mechanism is clear, but there are a number of details that should be resolved prior to publication.

The protocol doesn’t seem to include path MTU discovery when used with UDP. This brings the risk of problems relating to fragmentation. Section 5.1 says “The size of the request message SHOULD be at least 1024 bytes when the UDP transport mode is used”, but some paths may not support that packet size without fragmentation. Responses MUST NOT be larger than requests, but again the path MTU is not guaranteed to support at least 1024 byte responses. Section 5 notes that setting the “don’t fragment” bit is OPTIONAL in IPv4 it doesn’t include guidance on when, and when not, to set that bit. 

The draft should at least describe the risk that requests or responses sent over a particular path might be deterministically dropped due to MTU issues, and specify that clients should not keep trying to contact a consistently non-responsive server. In addition, if non-padded requests and responses would fit within an MTU significantly smaller than 1024 bytes, it might also be worth considering to define an MTU probing mechanism that sends smaller requests if the 1024 byte requests consistently fail for a particular server.

Section 5 states that “Multiple requests and responses can be exchanged over an established TCP connection. Clients MAY send multiple requests at once and servers MAY send responses out of order”. TCP connections serialise data for transmission, so cannot send multiple requests at once. The draft should perhaps rather say that multiple requests and responses can be exchanged over an established TCP connection, and that servers MUST respond to messages received on a TCP connection in the order they are received, but should not put any requirements on the relative ordering of responses to requests received on different TCP connections or between TCP and UDP.

How are TCP connections handed? Is the expectation that a new connection will be established for each request-response pair or that connections will remain open for some time and be used for multiple requests and responses? If the latter, what is the procedure for keeping connections alive (i.e., sending traffic to avoid NAT or firewall timeouts due to inactivity)?

How should TCP connections that fail be handled? Presumably a new connection is established and the request is re-tried, but if a connection to a particular server fails repeatedly should there be some form of back-off before retrying?

How is UDP packet loss handled? If a request is made over UDP and no response is received, does the client retry the request? If so, after how long and how many attempts are made? If a request to a server repeatedly fails, should clients follow some form of back-off algorithm to wait before retrying with that server? (RFC8085, especially Section 3.1.3, is likely relevant to this).

Does there need to be a mechanism to detect if a server fails, or goes out of service, to prevent repeated future requests to be made to that server?

Regards,
Colin