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

Davey Song <songlinjian@gmail.com> Wed, 26 September 2018 07:14 UTC

Return-Path: <songlinjian@gmail.com>
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 EC82F130E18; Wed, 26 Sep 2018 00:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 FkubzeKqBKcN; Wed, 26 Sep 2018 00:14:53 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1263F130DC8; Wed, 26 Sep 2018 00:14:53 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id l2-v6so16178485qtr.12; Wed, 26 Sep 2018 00:14:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q1+74/RE6aFIm5zuRfkVR7BmN2JB3WjaZ+s7W+zFr7E=; b=lTSWV9CDHyVQ79i2+LLMLKDL6yzj83D7PYa6FuF8Cn0kHViz5R0JB6RlzeGvLl5bhT 7wMudUDREUhG5wtoa+/0rqsbjHh44L94xAxDth0UDnFzHGtFI0i8NFaQpdboIC6dUtpc jy7QJXMV/k494mf4IZrHgWQMr/d/FmkJ8kWkkb11KJzbkT6IDqWCBflfxDFX9bd1B6nS Bi1kvv6FxUhOmrPEIVU3a6S2f19GOA0BfrBETOhxlLIQn+Z4djak6kzt60n3Kj16vhQC FdlObwZgztICEKOqDIe18yJH8SAKi2hqmuRCoJiVmXtAWa3k4L6A6OAA6jP9f60iR0wW iEJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q1+74/RE6aFIm5zuRfkVR7BmN2JB3WjaZ+s7W+zFr7E=; b=qLdSFg3X59JR03mu6J7KpwhvjalmfIMuplJG+d5U1M2o2ng9b2FA+ThxS67ytzLBJJ 9XJGHmRBjq/IwecvQ3BAXnjGvJ7cbq3ynVOXCwywjqLDr5hiwMrSU/ZsN16JrPCOeXdn OVAuCIFaJhdDqh5yMnIF3yGLUbp3fmQNr8AAGIZPcBkKQ+5LiFqesf3sVt+uajxq7/m1 DO2yN9OlfLREXIODWU9lW3TqWY7Ph8NtBX7LoLQ+lhaSsJTSyoxma20i21oB1As2Vf6N AjvXCY2Fg+PttwCmihv6KLbuijGNP6/4Wcq4mdPzziMz2JmEuhLUydAlm48a33/WMm5P kXWg==
X-Gm-Message-State: ABuFfoh/pfzvVZWxI0SIrFcP9goAUdvWAF83OKKUhbCUtbruzAjefXlr mDT19PwJmNYSfP/lm0HCsiQaN0UeIrK8dj/cassjm2qoc4chQQ==
X-Google-Smtp-Source: ACcGV62Wtt8AgRSaBjO/EB/aWzEaar7i9cfUjt31yuOM5QdBCf7iousbDKyvOhvttmgfYd85p1c/AFDhrgF85SymRns=
X-Received: by 2002:ac8:3414:: with SMTP id u20-v6mr3525720qtb.237.1537946092210; Wed, 26 Sep 2018 00:14:52 -0700 (PDT)
MIME-Version: 1.0
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> <2FEEAF29-E213-4DA3-8ECA-4EF51E170B50@employees.org>
In-Reply-To: <2FEEAF29-E213-4DA3-8ECA-4EF51E170B50@employees.org>
From: Davey Song <songlinjian@gmail.com>
Date: Wed, 26 Sep 2018 15:14:42 +0800
Message-ID: <CAAObRXJXv3iDg=k00FghuLQtSuogFD4FMr25krMSAXginAM5bg@mail.gmail.com>
To: otroan@employees.org
Cc: Gert Doering <gert@space.net>, dnsop <dnsop@ietf.org>, v6ops@ietf.org, 神明達哉 <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary="000000000000828d160576c0fac4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FLCDuO0w_i79EIpoZzKUpOBnjvo>
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 07:14:55 -0000

> 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?
>

Currently this draft only considers IPv4/IPv6 racing situation. The general
address
racing is already done for all clients (rfc6724). As mentioned in the
draft, NHE can
work independenly(without interferance) with the adoption of Client-side
HE.
If client's already support HE, it will query A & AAAA at the same time. NHE
can
help reduce the unnecessary traffic emitted by HE client becuase the AAAA
record
will be omitted or delayed if IPv6 connectivity is poorer. I don't see any
interferance now.


> 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.
>
It depends on how far you do the measurement to simulate the end users.
Some APM (application performance measurement) vendor like New Relic
provides sdk implementing on Apps to provide measurement data for analysis
and deliever a good performance monitoring and traffic engineering.
Some provide probes close to clients and edge.

I think maybe there is a crose-layer issues on this draft which should be
simple
 enough and aim IP layer issues. But right now lots of complected
application
layer complexities (like CDN, APM) are involved.


> Compare that with the data available to an MP-TCP host stack.
>

I think MP-TCP or other transmition protocol are based on stable,
high-performance ip layer.


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

HE(RFC8035) only focus on IP connection seletion right now accroding to the
problem statement:

   "Many communication protocols operating over the modern Internet use
   hostnames.  These often resolve to multiple IP addresses, each of
   which may have different performance and connectivity
   characteristics.  Since specific addresses or address families (IPv4
   or IPv6) may be blocked, broken, or sub-optimal on a network, clients
   that attempt multiple connections in parallel have a chance of
   establishing a connection more quickly.  This document specifies
   requirements for algorithms that reduce this user-visible delay and
   provides an example algorithm."


If there are other candidate connections, they also need a better IP
connectiviy as a bais I think.
NHE at least can give a indicaiton of poor connection for certain address
family (or address) .
It is potentially a low level routing founctions other than hight level
traffic scheduling tools.

Davey