...@tools.ietf.org;
'Mohacsi Janos'; 'Fred Baker';
draft-arifumi-6man-addr-select-confl...@tools.ietf.org
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
Let me re-send the following e-mail.
It did not make it to 6man ml web archive.
---
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.
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
Hi,
On 2010/01/19, at 10:26, Brian E Carpenter wrote:
Rémi,
On 2010-01-19 01:46, Rémi Denis-Courmont wrote:
On Fri, 15 Jan 2010 20:13:16 +0900, Arifumi Matsumoto arif...@nttv6.net
wrote:
* Fred's proposal.
- A host tries each pair of src and dst addresses to establish
a connection in a
...@tools.ietf.org;
'Mohacsi Janos'; 'Fred Baker';
draft-arifumi-6man-addr-select-confl...@tools.ietf.org
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
On Fri, 15 Jan 2010 20:13:16 +0900, Arifumi Matsumoto arif...@nttv6.net
wrote:
* 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,
Rémi,
On 2010-01-19 01:46, Rémi Denis-Courmont wrote:
On Fri, 15 Jan 2010 20:13:16 +0900, Arifumi Matsumoto arif...@nttv6.net
wrote:
* 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
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
;
Mohacsi Janos; Fred Baker;
draft-arifumi-6man-addr-select-confl...@tools.ietf.org
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
On Jan 15, 2010, at 8:07 AM, Dan Wing wrote:
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.
To me, that's the big issue. The point is to find
On Tue, 1 Dec 2009 22:19:10 -0800, Dan Wing dw...@cisco.com wrote:
I'm a bit worried about this. If e.g. the host is 100ms (RTT) away and
10 combinations work, you may end up creating TCP state (and getting
syn-acks back) on the destination host for 10 connections,
Are there servers that
Rémi Denis-Courmont allegedly wrote on 12/02/2009 5:17 AM:
On Tue, 1 Dec 2009 22:19:10 -0800, Dan Wing dw...@cisco.com wrote:
Are there servers that don't use SYN-cookies now-a-days?
IIRC, recent Linux kernel version have SYN-cookies disabled by default as
they were found to make things
Mailing List; Mohacsi Janos;
draft-arifumi-6man-addr-select-confl...@tools.ietf.org
Subject: RE: Thoughts on address selection
On Tue, 1 Dec 2009 22:19:10 -0800, Dan Wing dw...@cisco.com wrote:
I'm a bit worried about this. If e.g. the host is 100ms
(RTT) away and
10 combinations work
-ietf-6man-addr-select-considerati...@tools.ietf.org;
Mohacsi Janos; draft-arifumi-6man-addr-select-confl...@tools.ietf.org
Subject: Re: Thoughts on address selection
Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all
Brian,
On 2009/11/21, at 7:02, Brian E Carpenter wrote:
...
My second point is that assumptions like the best path is through a
prefix we both use are silly. Analysis of a common traceroute will
show that two random users tend to use two random ISPs. So a routing
policy tat starts from
On Fri, 20 Nov 2009, Stig Venaas wrote:
Fred Baker wrote:
On Nov 20, 2009, at 1:16 PM, Stig Venaas wrote:
My point is that if say the spacing is 10ms and the RTT is 100ms, you
will needlessly be trying many pairs (up to 10) before you realize that
perhaps the first you tried actually
On Nov 20, 2009, at 1:16 PM, Stig Venaas wrote:
My point is that if say the spacing is 10ms and the RTT is 100ms, you
will needlessly be trying many pairs (up to 10) before you realize
that
perhaps the first you tried actually works.
My first point is that if you don't wait multiple
On Nov 20, 2009, at 11:16 AM, Brian E Carpenter wrote:
If you are polite, and use some sort of exponential backoff like
REAP does, the time to discover a working pair can be quite long,
unless your first or second guess is correct.
That's kind of the point of the caching angle...
My second point is that assumptions like the best path is through a
prefix we both use are silly. Analysis of a common traceroute will
show that two random users tend to use two random ISPs. So a routing
policy tat starts from assume both users are using the same prefix
is a lost
On 2009-11-20 21:06, Fred Baker wrote:
On Nov 20, 2009, at 11:16 AM, Brian E Carpenter wrote:
If you are polite, and use some sort of exponential backoff like
REAP does, the time to discover a working pair can be quite long,
unless your first or second guess is correct.
That's kind of
Fred Baker wrote:
On Nov 20, 2009, at 1:16 PM, Stig Venaas wrote:
My point is that if say the spacing is 10ms and the RTT is 100ms, you
will needlessly be trying many pairs (up to 10) before you realize that
perhaps the first you tried actually works.
My first point is that if you don't
...
My second point is that assumptions like the best path is through a
prefix we both use are silly. Analysis of a common traceroute will
show that two random users tend to use two random ISPs. So a routing
policy tat starts from assume both users are using the same prefix
is a lost cause.
Brian E Carpenter wrote:
...
My second point is that assumptions like the best path is through a
prefix we both use are silly. Analysis of a common traceroute will
show that two random users tend to use two random ISPs. So a routing
policy tat starts from assume both users are using the same
Fred,
On 2009/11/18, at 23:07, Fred Baker wrote:
On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:
As I wrote in another e-mail, rather than giving over everything to hosts, I
think, giving hints for selecting addresses should be reasonable, at least
in some environments.
I
On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:
As I wrote in another e-mail, rather than giving over everything to
hosts, I think, giving hints for selecting addresses should be
reasonable, at least in some environments.
I would very much favor having an icmp message that
;
draft-ietf-6man-addr-select-considerati...@tools.ietf.org; IETF IPv6 Mailing
List; Mohacsi Janos; draft-arifumi-6man-addr-select-confl...@tools.ietf.org
Subject: Re: Thoughts on address selection
Fred,
On 2009/11/11, at 7:52, Fred Baker wrote:
On Nov 11, 2009, at 2:00 AM, Mohacsi Janos wrote:
I
Stig Venaas allegedly wrote on 11/18/2009 1:44 PM:
Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little
Scott Brim wrote:
Stig Venaas allegedly wrote on 11/18/2009 1:44 PM:
Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us
Fred,
On 2009/11/11, at 7:52, Fred Baker wrote:
On Nov 11, 2009, at 2:00 AM, Mohacsi Janos wrote:
I think this try_and_success_or_failure method can work in most
cases, however it has some burden for implementation and
operational point of view,
It does indeed, at least operationally.
Mohacsi,
I think It should be implemented the following way:
for each source address in some order {
create socket
bind (current source address)
for each destination address in some order {
connect (current destination address)
do {
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it
perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them closely and run them in parallel, I guess I
On Nov 18, 2009, at 6:43 PM, Arifumi Matsumoto wrote:
I'm not sure we can create perfect-in-every-environment
caching algorithm.
but you're convinced you can design an algorithm that consistently out-
thinks the network design?
wow. I'm not that optimistic.
Regarding this way of try-and-error approach,
I think It should be implemented the following way:
for each source address in some order {
create socket
bind (current source address)
for each destination address in some order {
connect (current
On 2009/11/18, at 18:46, Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it
perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them
Fred,
On 2009/11/18, at 18:50, Fred Baker wrote:
On Nov 18, 2009, at 6:43 PM, Arifumi Matsumoto wrote:
I'm not sure we can create perfect-in-every-environment
caching algorithm.
but you're convinced you can design an algorithm that consistently
out-thinks the network design?
IMO, we
On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:
As I wrote in another e-mail, rather than giving over everything to
hosts, I think, giving hints for selecting addresses should be
reasonable, at least in some environments.
I would very much favor having an icmp message that the
Brian E Carpenter allegedly wrote on 11/10/2009 9:54 AM:
Fred,
Another approach to problem 3 is to extract REAP from SHIM6 and
figure out how to use it to enhance address selection in practice.
... or any mechanism which tests src/dst address pairs. Note that
data packets and control
Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them closely and run them in
Dear All,
On Wed, 11 Nov 2009, Fred Baker wrote:
On Nov 11, 2009, at 2:00 AM, Mohacsi Janos wrote:
I think this try_and_success_or_failure method can work in most cases,
however it has some burden for implementation and operational point of
view,
It does indeed, at least operationally.
Mohacsi Janos wrote:
On Tue, 10 Nov 2009, Wes Beebee (wbeebee) wrote:
I think the simplest solution to (2) is, frankly, to open connections
at some
rate (if I have N addresses and my peer has M, send a SYN-or- whatever
on
successive pairs in the cross-product every K milliseconds until
On Wed, 11 Nov 2009, Brian Haberman wrote:
Mohacsi Janos wrote:
On Tue, 10 Nov 2009, Wes Beebee (wbeebee) wrote:
I think the simplest solution to (2) is, frankly, to open connections
at some
rate (if I have N addresses and my peer has M, send a SYN-or- whatever
on
successive pairs
I think the simplest solution to (2) is, frankly, to open connections
at some
rate (if I have N addresses and my peer has M, send a SYN-or- whatever
on
successive pairs in the cross-product every K milliseconds until I get
a SYN-ACK
on one of them, and then close all other sessions).
+1
I
On Tue, 10 Nov 2009, Wes Beebee (wbeebee) wrote:
I think the simplest solution to (2) is, frankly, to open connections
at some
rate (if I have N addresses and my peer has M, send a SYN-or- whatever
on
successive pairs in the cross-product every K milliseconds until I get
a SYN-ACK
on
On Nov 11, 2009, at 2:00 AM, Mohacsi Janos wrote:
I think this try_and_success_or_failure method can work in most
cases, however it has some burden for implementation and operational
point of view,
It does indeed, at least operationally. That is trivially solved for
sites one frequently
Fred,
Another approach to problem 3 is to extract REAP from SHIM6
and figure out how to use it to enhance address selection
in practice.
Brian
On 2009-11-10 14:42, Fred Baker wrote:
I'm following up on the discussion just had in 6man regarding address
selection. I have this awful feeling
Fred,
For your icmp see 3.4 in:
http://www.ietf.org/internet-drafts/draft-hain-ipv6-fwrh-02.txt
Tony
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Fred Baker
Sent: Tuesday, November 10, 2009 10:43 AM
To:
Fred,
On 2009/11/10, at 10:42, Fred Baker wrote:
I'm following up on the discussion just had in 6man regarding
address selection. I have this awful feeling that we are fighting
off the alligators and forgetting to drain the swamp.
Correct me if I am wrong. The objectives being the source
On Tue, 10 Nov 2009, Fred Baker wrote:
The simplest solution to (3), if my machine is in an administrative domain
facing an ISP, is to have my DMZ router perform the BCP 38 filter before the
datagram reaches the ISP, and in the failure case reply with some form of
ICMP message that says
48 matches
Mail list logo
