the addresses in the same order as queried, while it could happen the other way as well. The host in this example initiates TCP connections as soon as it gets responses in order to get a working connection up as soon as possible - in reality some implementations may want to wait for all addresses before initiating the first transport session connection. In this example, the host sends TCP SYN-messages over both IPv6 and IPv4 before it receives any response back from the peer. It could happen that the network reorders packets and TCP SYN/ACK-messages may arrive in a different order from the SYN-messages sent, but in this example the ordering is not changed. Instead, the IPv6 TCP connection completes first, and the host can start to use it. When the IPv4 connection completes, the host, in this example, discards it immediately by sending a TCP RST-message. However, the host might just as easily have taken the IPv4 connection into use as well, or made a decision later whether IPv4 or IPv6 seem to work better for the application. There are several different scenarios that can happen: for example the IPv4 connection could complete faster than IPv6, even if TCP SYN was first sent over IPv6. It is quite obvious that always trying both address families consumes twice the resources. This resource 'waste' can be optimized with some intelligence. For example, the host might allow some time for the first connection to succeed, and only after that try the second address family. This time can be as short as expected time for a TCP handshake to complete. RFC 6555 recommends a wait time of around 150-250 milliseconds [134]. Implementations can also go beyond this, for example, by keeping a record of which address families have been successful generally or for particular destinations, and starting connections with the address family that has worked better. The authors expect that it will take a couple of years before the best implementation strategies for Happy Eyeballs are found - and it is even possible that time proves that Hap