On Wed, 11 Nov 2009, Brian Haberman wrote:

Mohacsi Janos wrote:



On Tue, 10 Nov 2009, Wes Beebee (wbeebee) wrote:

I think the simplest solution to (2) is, frankly, to open connections
at some
rate (if I have N addresses and my peer has M, send a SYN-or- whatever
on
successive pairs in the cross-product every K milliseconds until I get
a SYN-ACK
on one of them, and then close all other sessions).

+1

I think what Fred mentioned is the only real way we're going to solve
the address selection problem.  If you don't try pairs and select which
one works first, then you're stuck trying to outguess the network design
at the operating system layer.  Any approach to do this will work in
some cases and fail in others.  It would be very hard for the IETF to
judge whether some combination of approaches works more often than it
fails - because that would involve some notion of what a "typical"
network topology is.

I think this try_and_success_or_failure method can work in most cases, however it has some burden for implementation and operational point of view, in my opinion:

1. the applications using getaddrinfo() library function has to be rewritten: most application written in principle of trying all available destination addresses, but no mechanism/logic in the codes to successively try all the source addresses. Of course this can be made hidden with some kernel implementation hacks, but this can be non-deterministic.

2. With application using UDP and/or multicast your try_and_success_or_failure might not scale. Will you send n(#source_address) X m(#destination_address) to the target node/group? Will it scale with multicast? Are you willing to increase the load of the e.g. DNS servers?

In what situations would m>1 if the destination is multicast?

None. Sending with multiple source address can be still problematical. But in the case of UDP might be more interesting....

Best Regards,
                Janos
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to