Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

Ole Troan <otroan@employees.org> Wed, 26 September 2018 06:10 UTC

Return-Path: <otroan@employees.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C156130DC9; Tue, 25 Sep 2018 23:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yx9U7BVatMJ; Tue, 25 Sep 2018 23:10:12 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926FE126BED; Tue, 25 Sep 2018 23:10:12 -0700 (PDT)
Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 1497EFECBEDF; Wed, 26 Sep 2018 06:10:12 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-44924CDD-E560-4FF7-B0C3-D5F04426F5F7"
Mime-Version: 1.0 (1.0)
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16A366)
In-Reply-To: <CAAObRXJd3Ym_JezijzFVGGUj6hnkLd78dA-B_oug1gZ_-kbeAw@mail.gmail.com>
Date: Wed, 26 Sep 2018 08:10:02 +0200
Cc: Gert Doering <gert@space.net>, dnsop <dnsop@ietf.org>, v6ops@ietf.org, 神明達哉 <jinmei@wide.ad.jp>
Content-Transfer-Encoding: 7bit
Message-Id: <2FEEAF29-E213-4DA3-8ECA-4EF51E170B50@employees.org>
References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <CAAObRXLWpXVbPyyxuzJH8osi+R1rdV8N8=Woqvq3UR9nk8kDaA@mail.gmail.com> <CAJE_bqd4jjeZy9Stp-v6O0VOyvEJiE9vW1BLuy-wzqPGvDagoQ@mail.gmail.com> <CAAObRX+6ktcD8i_aToKbX7UJoSPT0NMPV0xKqT8-k+7_d0R5Nw@mail.gmail.com> <20180925072015.GV11393@Space.Net> <CAAObRXKhS++5_cmvjTx3LY+ti6NbGj1NvtL6XeQGOvYuJKw0uw@mail.gmail.com> <3BDC24C2-6D51-4FF1-8A48-CAD4F8CEBF9C@employees.org> <CAAObRXJd3Ym_JezijzFVGGUj6hnkLd78dA-B_oug1gZ_-kbeAw@mail.gmail.com>
To: Davey Song <songlinjian@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Fj1OE23C6XdwbLzvTedSHPyfSmk>
Subject: Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2018 06:10:14 -0000

Davey,

If we’re discussing host based versus network based happy eyeballs, would it be naive to think that the network based HE would interfere with the client’s HE?

A router knows very little about end to end properties of a connection. It could of course do those measurements by looking deeply into packets, but it would still be restricted to it’s own topological location. Compare that with the data available to an MP-TCP host stack. 

And note I think HE can’t just be between v4 and v6, but between all the candidate connections between source and destination. 

Cheers,
Ole

On 26 Sep 2018, at 04:49, Davey Song <songlinjian@gmail.com> wrote:

>> But in the general case the network cannot.
>> Think host multi-homing.
> 
> Yes or no. 
> 
> Generally speaking the races of IPv6 and IPv4 connections on both network and client are going to be suffered by netowrk dynamics, including Multi-homing,  route flaps, roaming, or other network falilures. Extremely, a client can get a better IPv6 connection in one second (when IPv6 win the race), and lose it in next second. In such case, more sophisticated measurement should be done(on client or network) , for a longer period, on statistics of RTT and Failure rate, or combinations of them. But in IMHO, the assumption of HE is relatively stable network for short exchange connections. The dynamics exits but relatively rare or no notable impact on HE. So I see no such discussion in RFC8035.
> 
> Davey