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

Joe Abley <jabley@hopcount.ca> Wed, 26 September 2018 05:43 UTC

Return-Path: <jabley@hopcount.ca>
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 BBF68130DC9 for <dnsop@ietfa.amsl.com>; Tue, 25 Sep 2018 22:43:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 CnEWWzi5ItiI for <dnsop@ietfa.amsl.com>; Tue, 25 Sep 2018 22:43:43 -0700 (PDT)
Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 1737E130E01 for <dnsop@ietf.org>; Tue, 25 Sep 2018 22:43:43 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id m84-v6so23925285lje.10 for <dnsop@ietf.org>; Tue, 25 Sep 2018 22:43:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=qz24qd6jt9srLezpxAkqDeIeK2hXVUhF8H52lifYGZU=; b=PxhzQSQm/7TJQVQxkTAolx93CE42tHD5tLP4mjkirJr149Xq3zzR1CGQ4lA5IJX3dV yPcHvf+LzI3Y35erMtz9v1Q92MrfGXpsggbrYMaAEYwNkth7b2YramlG7vlPgYXaL2om N3zWBINeaR8oUWW77RGW49Vx+tUC6LBlctAR8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=qz24qd6jt9srLezpxAkqDeIeK2hXVUhF8H52lifYGZU=; b=RRDJnOKIIght7cKTnJCKxaP2V7zoywg7jEI6yobOfzwV7JDwgMw6lyQO/yJ47oRo4T rq9NZB2KczgYeNqrLm/2eGHOFR3unduUQ+BkB3oc1+AV8xT5Rj/G5DWe/bHy5Ikcb58p NhH8tklFbgvHu/K9TWwZTt8oUwke1ZhJjQomuXWkRvnUEz4z05THaU2zlL6GSjeMU9p1 0gCedffLlUL3vClO4skbKoig9Otn/KE1ZLiJXm1ewjEDEWweU3i/H56EuvAxr4szzkH0 adIiE+Ssy7LmAh+zve3BXmzXuXXOSLKsD/Pe9ZYXIGYoSXilGf6j+UrUtbIDiJc0k/eV HXbQ==
X-Gm-Message-State: ABuFfogrWi1vCjKHnG25MXhx9GpcqLcJy25go25R75zeBhHjVn8Mq1VO uB/oI1AaENUMv1g6XfE7CbracShwbe54I+g0EXMdWjxCB27Y2Q==
X-Google-Smtp-Source: ACcGV60NcaBfTDFf8W/PYoebYo7blm208yE/itTgA5WR58QCidHI5B9Y9K723rWs8m72C09L3yAlWPcD1VDzLAv2k7E=
X-Received: by 2002:a2e:9c4d:: with SMTP id t13-v6mr586030ljj.153.1537940620884; Tue, 25 Sep 2018 22:43:40 -0700 (PDT)
Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 25 Sep 2018 22:43:40 -0700
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (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> <CAKr6gn0p0ayWimZ8kWCAfNhLnpaK3j9WOGOmNCMXMac=cLR1Tw@mail.gmail.com> <F6F477B0-28DF-42C3-A8F6-F46BA2E0D119@delong.com> <CAJhMdTMr7O0fKs3AVmi8MY91xT0JQZhLvYwtXvD9+ZbvK9QYPg@mail.gmail.com> <CAKr6gn06aOiGfTKqi2bzqmbXDLn3qn87niw8c6pBDmkT5vJCGg@mail.gmail.com>
In-Reply-To: <CAKr6gn06aOiGfTKqi2bzqmbXDLn3qn87niw8c6pBDmkT5vJCGg@mail.gmail.com>
Date: Tue, 25 Sep 2018 22:43:40 -0700
Message-ID: <CAJhMdTPh29rnFuQKnSYcj1J4MtMRw6xqhUv=x0+9NAjZkq4ihw@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
Cc: dnsop WG <dnsop@ietf.org>, "<v6ops@ietf.org>" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Hs6JzgOhdExC1IHOWSMaeKV2dlk>
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 05:43:47 -0000

Having a predictable bias seems better than an unpredictable one.

> On Sep 25, 2018, at 22:28, George Michaelson <ggm@algebras.org> wrote:
>
> I'm not speaking for Owen. I'm speaking for myself. I asked a
> question. Is this really a long-term defensible thing to do? Do we
> want HE forever?
>
> run a race? thats fine. But, as the thread here notes, the
> second-by-second conditions which leads one TCP to return SYN-ACK
> before another can be volatile.
>
> run a race, but bias the race towards the one you like? okaaaay.. But
> once we're beyond a world where the V6 needs the bias, for anyone
> stuck on the vestigial 4-is-better space, this means they incurred
> *additional* connection penalty. wheres the control knob?
>
> now we're talking about tuning the bias, weighting the sum, tumbling
> the dice. I thought it was a crap shoot anyway...
>
> -G
>> On Wed, Sep 26, 2018 at 3:24 PM Joe Abley <jabley@hopcount.ca> wrote:
>>
>> What better idea did you mean?
>>
>> Being able to select a protocol based on what works best for the
>> end-user does not seem like a terrible end-state for the end-user,
>> short- or long-term.
>>
>>> On Sep 25, 2018, at 21:25, Owen DeLong <owen@delong.com> wrote:
>>>
>>> It was never a good idea. It was a necessary evil (kind of like NAT in that regard) to expeditiously deal with a somewhat tenacious (at the time) problem which has since been given a significantly better solution, but so long as the workaround appears to be working, people are loathe to put in the effort of implementing the actual solution.
>>>
>>> sigh… Human nature.
>>>
>>> Owen
>>>
>>>
>>>> On Sep 25, 2018, at 19:58 , George Michaelson <ggm@algebras.org> wrote:
>>>>
>>>> I have said before, but don't know if I still adhere to it, but
>>>> anyways, here's a question: How *long* do people think a biassing
>>>> mechanism like HE is a good idea?
>>>>
>>>> * is it a good idea *forever*
>>>>
>>>> * or is it a transition path mechanism which has an end-of-life?
>>>>
>>>> * how do we know, when its at end-of-life?
>>>>
>>>> I used to love HE. I now have a sense, I'm more neutral. Maybe, we
>>>> actually don't want modified, better happy eyeballs, because we want
>>>> simpler, more deterministic network stack outcomes with less bias
>>>> hooks?
>>>>
>>>> I barely register if I an on v4 any more. I assume I'm on 6 on many
>>>> networks. This is as an end-user. I guess if I am really an end user,
>>>> this belief I understand TCP and UDP is false, and I should stop
>>>> worrying (as an end user)
>>>> On Wed, Sep 26, 2018 at 12:49 PM 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
>>>>> _______________________________________________
>>>>> DNSOP mailing list
>>>>> DNSOP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop