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

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

 

> -----Original Message-----
> From: Arifumi Matsumoto [mailto:[e-mail]] 
> Sent: Monday, January 18, 2010 3:26 AM
> To: Dan Wing
> Cc: 'IETF IPv6 Mailing List'; "'Rémi Denis-Courmont'"; 
> [e-mail]; 
> [e-mail]; 
> 'Mohacsi Janos'; 'Fred Baker'; 
> [e-mail]
> 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: [e-mail]
>