[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-v6ops-addr-select-ps-02

Florian,
thank you for pointing out an interesting issue.

This problem can be thought to be conflict of local (client-side) optimization
and remote (server-side) optimization. Dst-rule 9 tries to implement local optimization of subsequent communication and breaks DNS round-robin technique 
which is optimization of the remote side traffic.

In my solution draft, which was approved as 6man wg item at Vancouver, some
proposed mechanisms for achieving/compensating local optimization are described
and analyzed, such as address policy distrbituion mechanism.

My suggestion for solving this problem is to change default address selection
algorithm to support remote optimization, namely invalidate dst-rule 9, and to
adopt other mechanism for local optimization if necessary.

As everyone mentioned, poor way of local optimization does harm for remote side
and sometimes for local side. Any kind of local optimization should be implemented
carefully by an administrator that figures out what size of address block his
site has, which address block the upstream network has, and what kind of address
selection policy doesn't conflict with DNS round-robin like remote optimization.

Moreover, local optimization is easier to be deployed than remote optimization is.
To implement remote optimization, almost all the nodes that connect to his server
have to support the mechanism for remote optimization. Changing the widely-used
standard document itself seems for me to be the best and possible way to go,
rather than standardizing an additional mechanism for remote optimization and convincing every user-OS vendor to implement it. 

Best regards,

Florian Weimer wrote:

I've also noticed that the draft fails to mention that Rule 9, when
applied by most of the client population on the Internet, results in
worse performance than no destination address sorting at all.

Rule 9 might offer a significant advantage in private deployments which
use non-IANA address allocation.  In other cases, routing is typically
not hierarchical at all, so that the length of the matching address
prefix is meaningless.



--
Arifumi Matsumoto
   IP Technology Expert Team
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: arifumi@nttv6.net