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

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

 

> -----Original Message-----
> From: Arifumi Matsumoto [mailto:[e-mail]] 
> Sent: Thursday, January 21, 2010 1:51 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
> 
> Hi,
> 
> >>> 
> >>> 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.
> 
> Agree.
> 
> > 
> >>>> - 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
> 
> almost every, but not every protocol.

Yes, I know.  RTP is a great example of a protocol that runs 
over UDP and is not a request/response protocol.

> And, that does not mean almost every user does not experience
> this problem.

I couldn't parse that double negative.

> > 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.
> 
> This looks another troublemaking mechanism.
> Can the operating system really tell it's application
> gave-up or successful socket close ?

If it was a successful close, and the application was 'pleased' (or someone
hit STOP on their web browser), the application will not try the 2nd or 3rd
addrinfo returned by the getaddrinfo() call.  If the application *does* try
the 2nd or 3rd addrinfo returned by the getaddrinfo() call, it indicates the
application was unhappy with the 1st one (it didn't connect [if TCP], or
didn't work as expected/required [if UDP]).

> > (b) seems implementable in the OS, and seems appealing.
> 
> I cannot see it's implementable without any harm.

I would like to discuss the potential before discarding the idea out of hand.
We need something smarter than just address selection; where to implement it?
In the OS, or in every application.

-d


> Kindest regards,
> 
> 
> >> 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]
> >> 
> > 
> 
> 
> --
> Arifumi Matsumoto
>   Secure Communication Project
>   NTT Information Sharing Platform Laboratories
>   E-mail: [e-mail]
>