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

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 15 Jan 2010 20:13:16 +0900

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.
** Con
- Impact for host protocol stack implementation.
  - Not a small change for the existing protocol stack and possibly
    applications.
- We do not have established caching algorithm.
  - 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 ;)
- Non-connected transport protocol complexity
  - Only applications know the connection success/failure if they use
    non-connected transport protocol like UDP.
- 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.

--
Arifumi Matsumoto
  Secure Communication Project
  NTT Information Sharing Platform Laboratories
  E-mail: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Jan 2010 08:07:30 -0800

> -----Original Message-----
> From: Arifumi Matsumoto [mailto:[email-masked]] 
> Sent: Friday, January 15, 2010 3:13 AM
> To: IETF IPv6 Mailing List
> Cc: Rémi Denis-Courmont; Dan Wing; 
> [email-masked]; 
> [email-masked]; 
> Mohacsi Janos; Fred Baker; 
> [email-masked]
> Subject: 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 a small change for the existing protocol stack and possibly

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.

>   - servers are loaded by unused sessions.

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

Not a problem caused by, or limited to, Fred's proposal.

> So, my suggestion is to have both mechanisms, while keeping 
> one mechianism work without the other protocol.

Sounds alright.

-d

---

From: Fred Baker <[email-masked]>
Date: Fri, 15 Jan 2010 10:53:51 -0800

>    to IPv6's address selection.  This means more users will

To me, that's the big issue. The point is to find a workable route,  
albeit not necessarily the best possible one, as "best" is at times in  
the eye of the beholder and influenced by events around us. One would  
like to place as little load on the target and the network as is  
necessary (don't send N^2 requests simultaneously and discard N^2-1)  
but at the same time trade temporary load for the ultimate resource,  
which is user time and frustration.

http://www.ipinc.net/IPv4.GIF

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 18 Jan 2010 20:25:57 +0900

Dan,

thank you for your comments.
My responses below.

>    to IPv6's address selection.  This means more users will 

not due to IPv6's address selection, but due to IPv6 connection
failure, aren't they ?

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

> people disabling IPv6 to improve their user experience, but that is their only

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.

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

OTOH, if the appropriate policy is distributed, every
application/protocols can make use of it.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 18 Jan 2010 13:46:34 +0100

>  which src and dst pair should be used to reach a certain dst.

This is awfully complicated. It might be implemented properly in some
high-profile apps, but it will be implemented incorrectly in many apps, and
it won't be implemented at all in others. To this day, there are still
applications that won't even try to fall-back from IPv6 to IPv4. Also, as
you mention, this simply doesn't fly for connection-less protocols. So
IMHO, source address selection should be hidden from apps into the
operating system as much as possible.

That of course does not preclude writing advices for robust applications on
what intelligent things they can and can *not* do. That could definitely
include trying all potential pairs in parallel instead of trying them
sequentially, if the application-layer protocol would handle it properly
anyway.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jan 2010 14:26:43 +1300

Rémi,

On 2010-01-19 01:46, Rémi Denis-Courmont wrote:
> it won't be implemented at all in others. 

It really doesn't belong in apps at all. It belongs in a shim common
to all transports. I would suggest giving serious consideration
to modifying the spec for the REAP component of SHIM6, which incidentally
doesn't rely on ICMP transparency.

However, it seems evident to me that we have to both make
site-wide 3484 policy distribution work, and make rapid trial-and-error
work. Neither one alone meets the need.

     Brian

To this day, there are still

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Jan 2010 22:57:55 -0800

> Sent: Monday, January 18, 2010 3:26 AM
> To: Dan Wing
> Cc: 'IETF IPv6 Mailing List'; "'Rémi Denis-Courmont'"; 
> 'Mohacsi Janos'; 'Fred Baker'; 
> Subject: Re: Discussion summary and next-step Re: Thoughts on 
> address selection
> 
> Dan,
> 

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.

> Ignoring Fred's

I am hoping to reduce reasons that users might disable IPv6.

> 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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Jan 2010 08:26:41 -0800

> Sent: Thursday, January 21, 2010 1:51 AM
> To: Dan Wing
> Cc: 'IETF IPv6 Mailing List'; "'"'Rémi Denis-Courmont'"'"; 
> Agree.
> 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.

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

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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 22 Jan 2010 11:19:34 +0900

Let me re-send the following e-mail.
It did not make it to 6man ml web archive.

---

Hi,

Agree.

Kindest regards,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 21 Jan 2010 18:50:58 +0900

Hi,

Agree.

Kindest regards,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 21 Jan 2010 18:39:32 +0900

Hi,

> doesn't rely on ICMP transparency.

We can implement this try-and-error approach mechanism in several ways,
and each of them has its own benefits and limitations.

And as Brian suggested, we can learn from the past/ongoing activity
like Windows APIs, SHIM6 and mptcp.

> work. Neither one alone meets the need.

Same here.

Kindest regards,