Stagger attempts and stop after the first success

Overlapping lifetimes do not imply simultaneous starts.

• Connection attempts SHOULD NOT start simultaneously. Start one destination, then later ones individually after a Connection Attempt Delay. Starting another attempt does not cancel an earlier one. A fixed250ms is one recommended default, distinct from the50ms DNS Resolution Delay (§5).
• A subsequent attempt MUST NOT start within10ms of the previous attempt. The recommended minimum is100ms; the delay SHOULD have an upper bound, currently recommended2s. RTT/history-based pacing can approximate the time of the previous attempt’s first SYN retransmission; it should not imitate later exponential backoff. A fixed250ms illustration is not a requirement to modify TCP retransmission timers (§§5,8).
• The example starts V6-A at0ms and V4-A at250ms. V6-A remains pending when V4-A starts; V4-A’s TCP handshake finishes at320ms. After one attempt succeeds, other not-yet-successful attempts SHOULD be cancelled and unattempted candidates SHOULD be ignored. The selected model follows those recommendations and deterministically breaks equal-time successes by list order as a local convention (§5).
• The asynchronous DNS query MAY be cancelled once a connection succeeds because new addresses will not be used for this connection. Nevertheless the DNS client resolver SHOULD process arriving network replies briefly, recommended1s, to populate its cache for later connections. Cancelling this race is not a requirement to discard every DNS reply (§5).
• A completed TCP connection is only the winner of this establishment process. Later TLS, HTTP, large-packet/MTU issues or service failures can still occur; RFC8305 does not guarantee application success or select a trust identity (§§9–10). The model uses supplied completion times, not real SYN/ACK packets.