Re: The IPv6 Transitional Preference Problem

AJ Jaghori <ciscoworkz@gmail.com> Fri, 25 June 2010 03:20 UTC

Return-Path: <ciscoworkz@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBF13A67AA for <ietf@core3.amsl.com>; Thu, 24 Jun 2010 20:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL31l+nQegJz for <ietf@core3.amsl.com>; Thu, 24 Jun 2010 20:20:51 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 042AC3A676A for <ietf@ietf.org>; Thu, 24 Jun 2010 20:20:50 -0700 (PDT)
Received: by gwb10 with SMTP id 10so1222490gwb.31 for <ietf@ietf.org>; Thu, 24 Jun 2010 20:20:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=3KuAnA4g37987Lz11tfbhXov8Bawyd+YYlia/256gmE=; b=l8fqgqiOyh+9S7SzMjcRDHXwwkd7uhkgnuIVqCUn/iDniA6W9f2S03yTERjNtQ0XM4 yB5jBjZt+7pKCnhH47JOMFT+omwq2v0w4s+JugFSAiTVrjlJQCrpsEpWVEWi5nSQaPWI SKXfNYV6j042rxVEfaNZ4LSdDhyA/rDBNOzrk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=S19W2YFR6Sv89xwOkLdzfgP91ztod4hHz5JvE1cadd9DYglPITebqKGw0i6+iDyK/T XzR7oj4K/YrrWQwm6QQj1JVJXpjbwNNniRVDl0Kp+P+BPXOlc/d331/tcl406x1h6LdT APNfp1n7/YS7vxXdGYEHVbBUwBkUvztHAvB4Y=
Received: by 10.101.146.3 with SMTP id y3mr5267ann.199.1277436056495; Thu, 24 Jun 2010 20:20:56 -0700 (PDT)
Received: from [10.55.12.111] (mobile-166-137-136-212.mycingular.net [166.137.136.212]) by mx.google.com with ESMTPS id e4sm6568566anb.25.2010.06.24.20.20.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Jun 2010 20:20:55 -0700 (PDT)
References: <201006231306.o5ND6M9T022481@fs4113.wdf.sap.corp> <14D6DC7C-FCD2-4EB9-AA56-ECF13A110C33@virtualized.org>
Message-Id: <76BAA00F-5CFA-4E0D-A82D-567496E79A0B@gmail.com>
From: AJ Jaghori <ciscoworkz@gmail.com>
To: David Conrad <drc@virtualized.org>
In-Reply-To: <14D6DC7C-FCD2-4EB9-AA56-ECF13A110C33@virtualized.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (7D11)
Mime-Version: 1.0 (iPhone Mail 7D11)
Subject: Re: The IPv6 Transitional Preference Problem
Date: Thu, 24 Jun 2010 23:20:44 -0400
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2010 03:20:53 -0000

there are many packet level tools ad server based packages that can  
help forecast and pipe v6 loads seamless to your user stack.

Sent from my iPhone (SDK).  Please excuse my brevity.

On Jun 24, 2010, at 1:23 PM, David Conrad <drc@virtualized.org> wrote:

> Martin,
>
> On Jun 23, 2010, at 6:06 AM, Martin Rex wrote:
>> What you described results in a negative incentive for servers to
>> become accessible under IPv6 as an alternative to IPv4.  That is a  
>> real problem.
>
> I guess I'm not seeing how it is a significant negative incentive to  
> servers.
>
>> If IPv6 connectivity is still bad, then the connection request will
>> not reach the server and the server will not notice.
>
> Right.  So, the only case where a parallel open would potentially  
> have any impact on the server is when there is good v6  
> connectivity.  Presumably, if a server operator has configured v6,  
> they are anticipating v6 load and will have engineered for that  
> load.  Since for any given session, the application will either  
> communicate via v4 or via v6, not both, the additional load on the  
> server will be exactly one additional communication initiation  
> event.  I honestly have difficulty seeing a server operator building  
> a system so close to the edge that this would be a real concern,  
> particularly given any server connected to the Internet today is  
> going to be subject to vastly more load due to random scans from  
> malware.
>
> In the serial case, there are two options: v4 first or v6 first.  If  
> v4 is chosen first, it is unlikely v6 will ever be used, thus the  
> server operator setting up v6 would be a waste of time.  If v6 is  
> chosen first, then the client will have to wait for the v6  
> initiation to time out in the case of bad v6 connectivity.  My guess  
> is that this would result in an increase in support calls to the  
> server operator ("why is your server so slow?") with the typical  
> support center response being "turn off v6 support".  I believe this  
> has been empirically demonstrated.
>
> I personally don't see how we'll get anywhere with v6 deployment  
> using the serial approach nor do I see any other options than  
> parallel vs. serial.  Since you believe parallel open to be a  
> problem, what is your proposed alternative?
>
> Regards,
> -drc
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf