Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line..

Rémi Després <despres.remi@laposte.net> Sat, 06 August 2011 14:43 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711F321F8565 for <v6ops@ietfa.amsl.com>; Sat, 6 Aug 2011 07:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Level:
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkRsHZokCza9 for <v6ops@ietfa.amsl.com>; Sat, 6 Aug 2011 07:43:55 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5A121F855A for <v6ops@ietf.org>; Sat, 6 Aug 2011 07:43:54 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id AEF727000085; Sat, 6 Aug 2011 16:44:13 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 805017000082; Sat, 6 Aug 2011 16:44:09 +0200 (CEST)
X-SFR-UUID: 20110806144409525.805017000082@msfrf2118.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com>
Date: Sat, 06 Aug 2011 16:44:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <032A834B-448A-4565-87EC-6DAF37CE2731@laposte.net>
References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> <D9712407-8D6D-49BC-B642-AD4DAD8E9CAB@apple.com> <m1QoM9f-0001eQC@stereo.hq.phicoh.net> <AA1FC05C-EFA4-46C9-B626-1D558DD6B844@apple.com> <1716B088-C4DF-414C-A8EB-8B778B7D89BC@nominum.com> <99FAF4A2-CD86-4F5E-9D0B-1D6E2DACD459@gmail.com> <m1QoX5D-0001gCC@stereo.hq.phicoh.net> <124FB632-ECED-4EFA-9102-BB9AB8C88096@gmail.com> <20110804012903.D8797126C146@drugs.dv.isc.org> <CAKD1Yr3bT6KWG+3YqHKWUsYBxZNj_ypwhd01ucgsU00Oz_XEeA@mail.gmail.com> <20110804024701.E9DD5126C85A@drugs.dv.isc.org> <CAKD1Yr15PEJcS32t8B_ps=VeO-nKJZKtRgtYidrkwv9zafLL1A@mail.gmail.com> <20110804033606.19231126CE1C@drugs.dv.isc.org> <20110804043805.EE880126D30C@drugs.dv.is> <c.org@apple.com> <CA+OBy1Mjpar6rSF2OCRJ6Mnsy4NMtNknMY_27CzUQRNzv56Vyw@mail.gmail.com> <B533E4F2-AC6E-4874-A99D-3E0C4B42CA62@apnic.net> <CA+OBy1P-eGv+-cwbezxTV9orH9LH5VXqJqUPs+jgszG1S0EvWg@mail.gmail.com> <47CBE645-71EE-48E6-9E3B-384E2C9BE821@apnic.net> <m1QosKS-0001jYC@stereo.hq.ph > <4E699BE0-1F0E-40D7-AE0F-EACFC5E3E343@apple.com>
To: james woodyatt <jhw@apple.com>
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line..
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Aug 2011 14:43:55 -0000

Le 4 août 2011 à 23:00, james woodyatt a écrit :

> On Aug 4, 2011, at 13:10 , Sander Steffann wrote:
>> 
>> I think it boils down to:
>> - If it is used when it gives better performance to the user: great.
>> - If it is used when the performance is roughly equal to IPv6: please use IPv6.
> 
> I don't know how to say this differently, so I'm just going to repeat myself.

> If you provision your networks so that IPv4 paths have longer round-trip times or are congested more often and/or to a greater degree, then we will prefer less congested IPv6 paths.
> 
> Furthermore, if you provision your networks so that IPv6 paths have longer round-trip times or are congested more often and/or to a greater degree, then we will prefer less congested IPv4/NAT paths.

Full agreement on these two (at least for applications that express indifference about v4 or v6 being used).
 
> Finally, if you provision your networks so that IPv4 and IPv6 exhibit "roughly equivalent" levels of path latency and congestion, then we're going to try very, very hard to use both IPv4 and IPv6 in "roughly equivalent" measure.

Serious disagreement on this one.
In this case, v6 MUST be preferred:
- If both paths are "good" (as they should be!), preference for IPv6 tends to increase the v6/v4 traffic ratio, which will lead to a visible fading out of IPv4 use.
- It's easier to implement, AFAIK, than trying hard to evenly split the traffic between v4 and V6.
Any solid argument against this?

Regards,
RD