RE: Discussion summary and next-step Re: Thoughts on address selection

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Arifumi Matsumoto [mailto:[e-mail]] 
> Sent: Friday, January 15, 2010 3:13 AM
> To: IETF IPv6 Mailing List
> Cc: Rémi Denis-Courmont; Dan Wing; 
> [e-mail]; 
> [e-mail]; 
> Mohacsi Janos; Fred Baker; 
> [e-mail]
> Subject: Discussion summary and next-step Re: Thoughts on 
> address selection
> 
> 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.


> ** 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.

>   - 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.

> - 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.

> - 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: [e-mail]
>