On Wed, 18 Nov 2009, Arifumi Matsumoto wrote:
Regarding this way of try-and-error approach,
I think It should be implemented the following way:
for each source address in some order {
create socket
bind (current source address)
for each destination address in some order {
connect (current destination address)
do {
"select" for K ms or a result, whichever comes first
} while (result was a connection attempt failing)
if result was a connection succeeding goto "connected"
}
destroy socket }
connected:
....
Even when a host can find a successful working address pair,
it is not always a desirable address.
From user's perspective, the pair found by chance might have
poorest bandwidth or latency.
From site administrator's perspective, the pair might not be
the best with regard to user experience, or provisioning cost.
For example, he may want to unload the traffic through CGN,
tunnel, translator middleboxes.
I'm not arguing that this approach is good or bad, but that
this approach fulfills all that we needed.
Agreed:
There is a need for address ordering mechanisms - preferably configurable
by the site administrator (with some minimal default in the operating
systems). This way you can have quicker the working
address pair which reasonably aligned to the policy.
But we should not expect that this policy can solve all the problems
outside of the site (or subnet, or host). The modest goal could be to
reasonable suggest some source addresses order based on the policy. The
destination address selection - no chance.
Policy definition in the routing currently done by routing protocols (most
notably the BGP). We cannot expect all the host run BGP, however they
might capable of doing that....
My point of view:
- There is need for policy for at least the source address selection
- The try_success_or_fail proposal of Fred Baker can help achieve better
user experience, but as I mentioned in one of my previous message it
requires changes how the applications are currently written.
Best Regards,
Janos Mohacsi
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
