Re: [IPv6] First hop selection [was: Adoption call for draft-bctb-6man-rfc6296-bis]

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 27 March 2024 18:29 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF13C169437 for <ipv6@ietfa.amsl.com>; Wed, 27 Mar 2024 11:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRYK2FZaM2Jp for <ipv6@ietfa.amsl.com>; Wed, 27 Mar 2024 11:29:41 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A98C169436 for <ipv6@ietf.org>; Wed, 27 Mar 2024 11:29:41 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6e782e955adso155074b3a.3 for <ipv6@ietf.org>; Wed, 27 Mar 2024 11:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711564180; x=1712168980; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Iod1f0wDAZ+o4RcEi/d8hpfKkmvsghcE780+tqjJ8MQ=; b=Uux963Rjaw4NqPfCtMe3+bFMh+FvoRcEEzg8EYIeaV7INl/Xj1km158Vnrg3kPRd2B rM+l9TA+73xSKF0nCqQjBJJ6TCGHzCybq8IWPGQW9t2hvQwahB0xmep8sS6O7t/87ySc T54gbuE14Euc29K63fJqu6CbQ+2D1BwjhpxuODtGjyEoJ7aC7TioVgY9/bCfFXNo/ZEv LtqVWh94ulRqTPjOvUee7iatwyqKvXmsvh1qmjsBABsY59NoI1gzAZ2tOGSYXkntfZEt D/yfqYGgL46Eti5NRSILjDD8iuMnJQaAsb33G/Tg8dRX+sW20ZzCt6eSsTXYxdnW0at4 xdeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711564180; x=1712168980; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Iod1f0wDAZ+o4RcEi/d8hpfKkmvsghcE780+tqjJ8MQ=; b=sx390RX8SIJ2qdjBRCrGi1wyOer17E7dYWPJoBt8Cv43XH2YtraW9Rgs3MBgfAPPmk WJWE9aQO1QeIRQUYvbxrAyvrqdtyf3VfSdg47wRI4SxlvpkCHwkarfoUaMUi7fb2UZLk sK2otnhKTEDYfhJcI+GPwwt0VMLsbAxhirTewQKsAF9Sl1jQunVCm5cGFsma8HjmrptM TTv5YUFOXKjpDSkQclS3h40HNYRSExBhUcZ+CwgqJhfZFun3YxVIzmgg9t/xDpLw1Ymw Skzvp+5c9M4z5rVOPyfsN7n1P0+tUQ9xDf8LGUSyVFTrf1uFh5Ot70sNpqk6lSduCIA+ gxBQ==
X-Gm-Message-State: AOJu0YxgABDR0/0BjFF9BjA1YfnFcvZmsgxF2DXlAB1+xBJ2SJtIzEY4 UsaGYxuUFvu2fr+rYBVynlYMt04YLiGqLn34a3R1VSrogLvKvfFt1UYtrwO+
X-Google-Smtp-Source: AGHT+IH30pPZDpC3L2b3esyqWil4xvZ7hox57x3SOzPqCr1fTZUO4oUNh3oBbHBPBDEa9UviFIx1Hw==
X-Received: by 2002:a05:6a00:3c81:b0:6ea:7647:282d with SMTP id lm1-20020a056a003c8100b006ea7647282dmr654553pfb.29.1711564179988; Wed, 27 Mar 2024 11:29:39 -0700 (PDT)
Received: from [172.20.5.106] ([210.55.135.122]) by smtp.gmail.com with ESMTPSA id i25-20020aa79099000000b006eac4297ed3sm2426642pfa.20.2024.03.27.11.29.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Mar 2024 11:29:39 -0700 (PDT)
Message-ID: <f0b317a8-c124-489b-bf52-b04a722294f2@gmail.com>
Date: Thu, 28 Mar 2024 07:29:34 +1300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, Ted Lemon <mellon@fugue.com>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
References: <CAPt1N1=eFFOkuJShykJn1_BZuY3BAGTgza=a7Hnp4JKZetxiCA@mail.gmail.com> <2A798A60-1934-488B-8FA8-E6E68AE95EE9@consulintel.es> <64ffe90f-8aea-ecbf-de1c-73d880a7ddd5@gmail.com> <CAPt1N1kkMzZgkJfykyZ1cffPhYFmEMOaRLP450jWmHoBvAj8Zw@mail.gmail.com> <CAKD1Yr3U7_Lk_MumEEFjHyfT2YR0u2DRpr9sPXB+Ziy6cO4C5Q@mail.gmail.com> <ZfvTkBLdMf873H2d@eidolon.nox.tf> <d131e3a5-9ec0-468b-9f62-9cf131d12b55@gmail.com> <ZgEltLsdDiqq9R2e@eidolon.nox.tf> <22ef98a2-e310-46f6-ab10-0b41454d8310@gmail.com> <CAKD1Yr1Gw3LmL-wv6YxcZbfRJUvVTBU6CdaQtOjR8FC8tsSvyQ@mail.gmail.com> <01B108A8-B94B-4964-A5B0-0F1657A8CCDC@employees.org> <CAPt1N1mkOKxEivsj-om+caiSD_AVChLLWxuOgKSrvbZO7wQ1wQ@mail.gmail.com> <m1rp9xB-0000KeC@stereo.hq.phicoh.net> <CAPt1N1ndW9=Moc12RrWOCOxrThZXc=yg9j6yRd1oOB+zrXMtZQ@mail.gmail.com> <e6e78e01-c74d-49b0-8623-4ae32c5a32f2@gmail.com> <CAPt1N1kJ5CjdJzUh3R0cY1wunjHdonFzTPjsx6hVmUfvgOgGXw@mail.gmail.com> <afdd79df453c49029a498f0da4239867@huawei.com>
Content-Language: en-US
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <afdd79df453c49029a498f0da4239867@huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1U-jIFvJkgasxhNVq-3shHxByOU>
Subject: Re: [IPv6] First hop selection [was: Adoption call for draft-bctb-6man-rfc6296-bis]
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2024 18:29:45 -0000

On 27-Mar-24 20:17, Vasilenko Eduard wrote:
> Brian is replacing happy eyeballs 

Not exactly. Some apps will still want to make their own optimization. My thinking is that the more that information about the best {source, destination} pairs can be shared the better, so having the pairs ranked by the o/s itself will give the best possible results.

    Brian


> because he is proposing to check DA properties in some tests. If we know enough about DA quality then we do not need happy eyeballs race/competition/duplicate_traffic.
> 
> It is indeed better to cache and share such information per host, not per session.
> 
> Ed/
> 
> *From:* ipv6 <ipv6-bounces@ietf.org> *On Behalf Of * Ted Lemon
> *Sent:* Tuesday, March 26, 2024 22:51
> *To:* Brian E Carpenter <brian.e.carpenter@gmail.com>
> *Cc:* ipv6@ietf.org
> *Subject:* Re: [IPv6] First hop selection [was: Adoption call for draft-bctb-6man-rfc6296-bis]
> 
> Right. Such APIs exist, but socket/getaddrinfo isn’t that. I guess getaddrinfo could return a sorted list? But you still need to do happy eyeballs and track changes, so it’s not really adequate to do a synchronous API no matter what.
> 
> Op di 26 mrt 2024 om 14:46 schreef Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
> 
>     On 27-Mar-24 06:15, Ted Lemon wrote:
>      >
>      >
>      > Op di 26 mrt 2024 om 12:47 schreef Philip Homburg <pch-ipv6-ietf-10@u-1.phicoh.com <mailto:pch-ipv6-ietf-10@u-1.phicoh.com> <mailto:pch-ipv6-ietf-10@u-1.phicoh.com <mailto:pch-ipv6-ietf-10@u-1.phicoh.com>>>
>      >
>      >      >It seems like in order for this to work each possible destination address
>      >      >has to be evaluated for reachability and then the set of source addresses
>      >      >that could combine with it can be constrained using the selected interface
>      >      >for that destination. And then you use source/dest address selection to
>      >      >pick the source/destination pair from each of these result sets, and do
>      >      >Happy Eyeballs to prioritize which S,D pairs you try. I don't see how you
>      >      >could do this right if you start by picking a destination address.
>      >
>      >     When it comes to destination addresses we can make one of two assumptions:
>      >     1) The Internet is professionally maintained and in general every destination
>      >         address you find is reachable. In that case, order destination addresses
>      >         in some way and try them in order. Of course sometimes there may be an
>      >         issue, but if that is rare it is fine. And operators like users who
>      >         complain because many operators are using user to detect problems. That
>      >         why there is a push for IPv6-mostly.
>      >     2) Whether a destination address works or not is mostly random. In that case
>      >         get advanced forms of happy eyeballs to dynamically pick the most likely
>      >         destination address and quickly try other ones as well to minimize
>      >         impact on the user.
>      >
>      >     For each destination address you try, there is essentially the same reasoning
>      >     for source addresses: in a well maintained network there is an algorithm
>      >     to select source addresses. If there is more randomness then trying multiple
>      >     source addresses for each destination address might be required.
>      >
>      >
>      > Oh, right, rule 5.5 means we have multiple possible routes per destination to deal with. So we have an extra iteration to do there. But still, ideally if all upstreams are working, the first s,d pair that you choose this way will work.
> 
>     To me, this very interesting discussion underlines that the model presented to the application by the BSD socket model via getaddrinfo() is at best unfriendly and at worst wrong. The app needs a sorted list of address pairs, not a sorted list of destination addresses with no information about the source addresses that will be used.
> 
>         Brian
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
>