> -----Original Message-----
> From: Arifumi Matsumoto [mailto:arif...@nttv6.net]
> Sent: Monday, January 18, 2010 3:26 AM
> To: Dan Wing
> Cc: 'IETF IPv6 Mailing List'; "'Rémi Denis-Courmont'";
> draft-ietf-6man-addr-select-...@tools.ietf.org;
> draft-ietf-6man-addr-select-considerati...@tools.ietf.org;
> 'Mohacsi Janos'; 'Fred Baker';
> draft-arifumi-6man-addr-select-confl...@tools.ietf.org
> Subject: Re: Discussion summary and next-step Re: Thoughts on
> address selection
>
> Dan,
>
> thank you for your comments.
> My responses below.
>
> >>
> >> Hi,
> >>
> >> let me summarize the discussion we had about address selection,
> >> and move on to the next-step.
> >>
> >> The discussion was about a try-and-error based mechanism proposed
> >> by Fred Baker, and the address selection design team's proposal,
> >> which is based on policy distribution.
> >>
> >>
> >> * Fred's proposal.
> >> - A host tries each pair of src and dst addresses to establish
> >> a connection in a short time period.
> >> - A host can make use of ICMP error messages indicating that the
> >> src address should be this, or the src address is simply wrong.
> >> - A host can have cache for the reachability status, which stores
> >> which src and dst pair should be used to reach a certain dst.
> >>
> >> ** Pro
> >> - A connection can be established as far as one working
> pair exists.
> >> - Routing status can be reflected to address selection directly,
> >> which means no need for intermediate agent and information
> >> conversion.
> >
> > Missing a Pro that I consider significant:
> >
> > - Users will no longer experience multi-second connection
> delays due
> > to IPv6's address selection. This means more users will
> > leave IPv6 enabled.
>
> not due to IPv6's address selection, but due to IPv6 connection
> failure, aren't they ?
The connection failure is caused by incorrect address selection.
I don't see how to separate the two.
And users don't care -- they simply disable IPv6 if it slows
down their experience.
> >> ** Con
> >> - Impact for host protocol stack implementation.
> >> - Not a small change for the existing protocol stack and possibly
> >> applications.
> >
> > It's really the applications that have to change so that they
> > are more aggressively going through the getaddrinfo()-sorted
> > addresses to get a connection established.
> >
> >> - We do not have established caching algorithm.
> >
> > Not a problem caused by, or limited to, Fred's proposal.
> Ignoring Fred's
> > proposal for a second, RFC3484 address selection policies
> could be wrong (as
> > we all know) and perhaps they should be able to
> learn/notice failures.
>
> This is what I meant by the combination with Fred's proposal and
> policy distribution.
>
> Of course, it is beneficial to have this combination, but
> such caches are not essential for policy distribution way.
>
> >> - Caching does good for static environment, and can harm for
> >> dynamically changing environment.
> >> - Network outage invokes cache reconstruction.
> >> - Conformance with network policy, user experience.
> >> - A connection success does not mean conformance with site network
> >> policy, nor user experience, such as delay and bandwidth.
> >> - A site may have demands for preference control on address
> >> selection,
> >> such as IPv6 and IPv4 prioritization, in order to
> decrease network
> >> provisioning cost or to enhance user experience.
> >> - Extra load for network and host.
> >> - routers have to send error messages.
> >> - servers are loaded by unused sessions.
> >> - extra CO2 emission ;)
> >
> > That amount of extra traffic is tied to how caching and
> dynamic learning might
> > be specified. We could, if this is a sensitive issue,
> specify that things
> > work as slowly as today (e.g., multi-second second
> connection timeouts before
> > trying another IP address). However, this creates a very
> poor user experience
> > which today can only be resolved by the user disabling
> IPv6! We do not want
> > people disabling IPv6 to improve their user experience, but
> that is their only
> > choice today.
>
> There are so many reasons that makes users disable IPv6, such as
> network unreachability, and application IPv6 related
> mal-functioning,...
> This proposal does not solve all the cases.
I am hoping to reduce reasons that users might disable IPv6.
> >> - Non-connected transport protocol complexity
> >> - Only applications know the connection success/failure
> if they use
> >> non-connected transport protocol like UDP.
> >
> > Not a problem caused by, or limited to, Fred's proposal.
>
> I cannot get why.
>
> If the kernel caches address selection information, it
> has to have connection success/failure information.
Yes, and that works even for UDP:
a. the OS can see an incoming UDP response packet,
because almost every protocol is a request/response protocol
or:
b. the OS can see the application gave up on one socket
and is trying another socket. This indicates the application
was -- for whatever reason -- 'displeased' with the address
selection made by the OS.
(b) seems implementable in the OS, and seems appealing.
-d
> OTOH, if the appropriate policy is distributed, every
> application/protocols can make use of it.
>
> >
> >> - Spoils DNS round-robin based load balancing
> >> - Network side(routers) cannot have effects on dst address
> selection.
> >> Only can have effects on src address selection.
> >>
> >>
> >> * Design Team proposal.
> >> - Network side distributes address selection policy to hosts.
> >>
> >> ** Pro
> >> - No impact on protocol stack, as far as it implements RFC 3484.
> >> - At least, network policy can be implemented.
> >> This does not always lead to user experience enhancement.
> >> - Network side can have effects on dst address selection also.
> >> ** Con
> >> - Hosts have to have functionalito for receiving and
> processing policy
> >> information.
> >> - To make use of routing information, routing information has to be
> >> converted to address selection policy at intermediate nodes, and
> >> frequently updatable policy distribution mechanism is necessary,
> >> such as DHCP reconfigure.
> >>
> >>
> >> * Considerations towards next-step
> >> Design team proposal and Fred proposal have different applicability
> >> domains, and one does not include the other.
> >> Fred proposal works more nicely if combined with Design
> >> team'smechanism.
> >> Design team proposal can work by itself, but if combined with
> >> Fred proposal, the applicability will be broader.
> >> So, my suggestion is to have both mechanisms, while keeping
> >> one mechianism work without the other protocol.
> >
> > Sounds alright.
> >
> > -d
>
> --
> Arifumi Matsumoto
> Secure Communication Project
> NTT Information Sharing Platform Laboratories
> E-mail: arif...@nttv6.net
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
