Dynamic AMT relay resolution

[Laur04]

In most implementations, general names like amt-relay.m2icast.net are queried in a round robin fashion until data is received from one. Currently, the tunnels built in this app try only the first address and, if that fails, fail without attempting to recover. Dynamic relay selection should be added.

[lgiuliano]

The way VLC works is it receives the list of all the A records for the relay (by default, amt-relay.m2icast.net) and iterates through each until it starts receiving data. I believe the default is 2s before switching to the next one. In this way you end up with relay redundancy and load balancing, but not optimality. A more optimal solution would be for the gw to ping all the relays and then start with the one with the lowest latency time.

[GrumpyOldTroll]

RFC 8777 describes a design for parallelized discovery of relays based on Happy Eyeballs (RFC 8305) tuned for AMT:
https://www.rfc-editor.org/rfc/rfc8777#name-relay-discovery-operation

The VLC approach of using a specific DNS name for the relay instead of trying to discover the relay name based on the source IP of the (S,G) would count as "administrative configuration" that takes the place of the first few steps RFC 8777 goes over, but it still has some advice about how to do the parallel discovery.

(For instance, you don't need to ping the relays, because you can instead get a round trip time for each relay by sending the initial part of the AMT handshake and continuing to the rest of the handshake with the fastest one first.)

[lgiuliano]

Ahh, using RTT from the initial part of the AMT handshake to select the closest relay is a much better idea. Thanks for pointing that out, Jake!