Code change:
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 cannot 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.

Related discussion:
text: After this point, any pending send operation is resumed to the bound peer address. <del> 5. </del> <ins> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. 5.1. The initiator MAY send multiple "return_routability_check" messages of type path_challenge to cater for packet loss on the probed path. Each path_challenge SHOULD go into different transport packets. (Note that the DTLS implementation may not have control over the packetization done by the transport layer.) 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. 5.2. 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 NOT enforce this behaviour 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. 5.3. 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. 6. </ins> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC