Draft: draft-ietf-tls-dtls-rrc

Commentary: and 
 For example , allow multiple outstanding path_challenge messages to cater for potential packet loss . 
 We want to limit the application data sent to a reasonable threshold while we run the RRC . 
 RFC 9000 , section 8 " address validation " ( second paragraph , last line ): 3 times the amount of data received . 
 Here is the text : Address Validation Address validation ensures that an endpoint can not be used for a traffic amplification attack . In such an attack , a packet is sent to a server with spoofed source address information that identifies a victim . If a server generates more or larger packets in response to that packet , the attacker can use the server to send more data toward the victim than it would be able to send on its own . The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims . Therefore , after receiving packets from an address that is not yet validated , an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address . This limit on the size of responses is known as the anti - amplification limit .
Note however that, irrespective of CID, if RRC has been successfully
negotiated by the peers, path validation can be used at any time by
either endpoint.  For instance, an endpoint might use RRC to check
that a peer is still in possession of its address after a period of
quiescence.
This document reuses the definition of "anti-amplification limit"
from RFC9000 to mean three times the amount of data received from an
unvalidated address.  This includes all DTLS records originating from
that source address, excluding discarded ones.
path-challenge-reqs and path-response-reqs contain the requirements
for the initiator and responder roles, broken down per protocol
phase.
The initiator MAY send multiple "return_routability_check"
messages of type path_challenge to cater for packet loss on the
probed path.
The transmission of subsequent path_challenge messages SHOULD
be paced to decrease the chance of loss.
Each path_challenge message MUST contain random data.
The initiator MAY use padding using the record padding mechanism
available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the
sending direction) up to the anti-amplification limit to probe if
the path MTU (PMTU) for the new path is still acceptable.
The responder MUST NOT delay sending an elicited path_response
message.
The responder MUST send exactly one path_response messages for
each received path_request.
The responder MUST send the path_response on the network path
where the corresponding path_challenge has been received, so that
validation succeeds only if the path is functional in both
directions.
The initiator MUST silently discard any invalid path_response it
receives.
Note that RRC does not cater for PMTU discovery on the reverse path.
If the responder wants to do PMTU discovery using RRC, it should
initiate a new path validation procedure.
When setting T, implementations are cautioned that the new path could
have a longer round-trip time (RTT) than the original.
In settings where there is external information about the RTT of the
active path, implementations SHOULD use T = 3xRTT.
If an implementation has no way to obtain information regarding the
RTT of the active path, a value of 1s SHOULD be used.
Profiles for specific deployment environments - for example,
constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a
different, more suitable value.