Re: mini-cores (was Re: ULA-C)

[Iljitsch van Beijnum <iljitsch at muada.com>]

On 20-sep-2007, at 16:52, Keith Moore wrote:

> > 6to4 is a crapshoot, it can be
> > reasonable or it can completely fail, with everything in between. But
> > it's never going to be better than native IPv4, obviously.

> No, not obviously - because if the application has a need to do  
> address
> referral then there are conditions in which the 6to4 address will work
> better.

I was talking about performance. I guess even there there are a few  
cases where 6to4 can do better than the IPv4 it's carried over, but  
that should be rare.

> > I agree that this is an important issue, but I fail to see how this
> > relates to applications knowing about addresses, unless applications
> > are going to do their own performance testing, which I don't  
> > recommend.

> p2p applications are doing this already.

Do you mean BitTorrent? Those applications don't really test  
performance, but simply use different addresses concurrently. Which  
is an excellent way to make the question of which address performs  
better moot, by the way.

> > As I said, a good start would be that API because once applications
> > use it, people working on better address selection etc have a  
> > place to
> > insert their stuff and improve performance of real applications
> > without having to rewrite the application.

> I spent a fair amount of time trying to come up with an API that would
> let applications push this decision-making to a lower layer while
> allowing that lower layer to make those decisions effectively based on
> the needs of that particular application.From ietf-bounces at ietf.org Thu Sep 20 13:00:05 2007
Return-path: <ietf-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IYPFZ-0002sF-4b; Thu, 20 Sep 2007 12:51:37 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPFT-0002kp-8C
	for ietf at ietf.org; Thu, 20 Sep 2007 12:51:31 -0400
Received: from sequoia.muada.com ([83.149.65.1])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYPFS-0004v2-F9
	for ietf at ietf.org; Thu, 20 Sep 2007 12:51:30 -0400
Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28])
	(authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8KGmfg3017606
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 20 Sep 2007 18:48:42 +0200 (CEST)
	(envelope-from iljitsch at muada.com)
In-Reply-To: <46F28942.4050207 at cs.utk.edu>
References: <11452.1189607641 at marajade.sandelman.ca>	<61769.1189616824 at sa.vix.com>	<3009e5840709121107o78cdd94fu907ab4de187b5d78 at mail.gmail.com>	<46E90E04.30000 at piuha.net>	<0F18F924-0B75-4F7C-9DCF-2759E9CECB61 at cs.ucla.edu>	<46EDFEC0.4060308 at piuha.net>
	<07ea01c7fa05$e68ae030$b3a0a090$ at net>	<p06240600c315a807196a at [98.207.7.244]>
	<42439.1190137947 at sa.vix.com> <46F04CCE.6010503 at cs.utk.edu>
	<F175DA5D-FA1F-423D-BAA2-E297AF6AFCBC at muada.com>
	<46F26871.90808 at cs.utk.edu>
	<57B7A54D-0A57-48D0-9F60-BF1647C291B9 at muada.com>
	<46F26D16.5020706 at cs.utk.edu>
	<4D430618-1877-4221-BC0C-B85E626F8376 at muada.com>
	<46F28942.4050207 at cs.utk.edu>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9FD41F3D-9AAA-45F8-BA60-5AB2C95B7B37 at muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch at muada.com>
Date: Thu, 20 Sep 2007 18:51:17 +0200
To: Keith Moore <moore at cs.utk.edu>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: IETF Discussion <ietf at ietf.org>
Subject: Re: mini-cores (was Re: ULA-C)
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

On 20-sep-2007, at 16:52, Keith Moore wrote:

> > 6to4 is a crapshoot, it can be
> > reasonable or it can completely fail, with everything in between. But
> > it's never going to be better than native IPv4, obviously.

> No, not obviously - because if the application has a need to do  
> address
> referral then there are conditions in which the 6to4 address will work
> better.

I was talking about performance. I guess even there there are a few  
cases where 6to4 can do better than the IPv4 it's carried over, but  
that should be rare.

> > I agree that this is an important issue, but I fail to see how this
> > relates to applications knowing about addresses, unless applications
> > are going to do their own performance testing, which I don't  
> > recommend.

> p2p applications are doing this already.

Do you mean BitTorrent? Those applications don't really test  
performance, but simply use different addresses concurrently. Which  
is an excellent way to make the question of which address performs  
better moot, by the way.

> > As I said, a good start would be that API because once applications
> > use it, people working on better address selection etc have a  
> > place to
> > insert their stuff and improve performance of real applications
> > without having to rewrite the application.

> I spent a fair amount of time trying to come up with an API that would
> let applications push this decision-making to a lower layer while
> allowing that lower layer to make those decisions effectively based on
> the needs of that particular application.  That API ended up looking
> fairly complex.  There are lots of factors that influence address  
> selection.

Yes, communicating application needs back and forth would be tricky.  
For instance, suppose I have two links: one is 2 Mbps ADSL. This is  
not so bad that an application can't run, but if my other link is  
1000 Mbps, then the application would probably want to use that link.  
But the application doesn't know if that's the case, it could also be  
a GPRS link with enormous latency and virtually no bandwidth. So what  
does the application say?

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf