Re: [v6ops] [tcpm] Flow Label Load Balancing

Fernando Gont <fernando@gont.com.ar> Sun, 29 November 2020 05:53 UTC

Return-Path: <fernando@gont.com.ar>
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 9140F3A11AA; Sat, 28 Nov 2020 21:53:32 -0800 (PST)
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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 04Z64h8ti81m; Sat, 28 Nov 2020 21:53:28 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9DC3A11A9; Sat, 28 Nov 2020 21:53:13 -0800 (PST)
Received: from [IPv6:2800:810:464:8164:d564:510f:6fb3:4524] (unknown [IPv6:2800:810:464:8164:d564:510f:6fb3:4524]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 69F7B280878; Sun, 29 Nov 2020 05:53:09 +0000 (UTC)
To: Tom Herbert <tom@herbertland.com>, Alexander Azimov <a.e.azimov@gmail.com>
Cc: Mark Smith <markzzzsmith@gmail.com>, IPv6 Operations <v6ops@ietf.org>, tcpm <tcpm@ietf.org>
References: <CAEGSd=DY8t8Skor+b6LSopzecoUUzUZhti9s0kdooLZGxPEt+w@mail.gmail.com> <d29042a7-742b-a445-cf60-2773e5515ae5@gont.com.ar> <CALx6S37+1duoNGR3dZWesHsZvx15kX9wCWufPMh=esvMaSMF_g@mail.gmail.com> <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <CALx6S37t4jump6S-R5_xdo5DF+RnHtT4rU5-RuiC-2GQ0PXxkQ@mail.gmail.com> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <CALx6S34uCrA1QdvLV8fpRKaJGLWMgtCmBCnrsBjU3TS+kXUs3Q@mail.gmail.com> <CAO42Z2xn_+7EVpjGyEU3aAdBmt1h=a4MPXFjjoTi_JeM2w9pkg@mail.gmail.com> <f66cbccd-55ed-375b-743b-7fc6c48a50c2@gont.com.ar> <CAO42Z2xqU4gs9iP=u_0Z16Qk+U24_YH0h5vTmJRJ5XZXZ0nweQ@mail.gmail.com> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <CAEGSd=A_e-db8m2VN+2wEuXj9e+GTq7brYfY_fwW7tysUr19Ng@mail.gmail.com> <CALx6S34xQF-PHQRqom_O8=amoRFmVrzHL-qh8765mtr1XnF2Wg@mail.gmail.com>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <d59e1785-672d-8cc7-f844-51c64a440a57@gont.com.ar>
Date: Sun, 29 Nov 2020 02:53:01 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CALx6S34xQF-PHQRqom_O8=amoRFmVrzHL-qh8765mtr1XnF2Wg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_ESh2-TMzODbhq5WryIw5upfeh4>
Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 29 Nov 2020 05:53:33 -0000

Tom,

On 28/11/20 15:27, Tom Herbert wrote:
[....]
>> While not questioning innovative technologies that take care of traffic, a 'good' repair time counts in seconds. 'Bad' repair time, when the control plane becomes broken or a famous silent drop happens counts in minutes and requires a network engineer to be summoned. If TCP can fix itself in milliseconds - it's great. And it is needed by real operations. You also missing part when something happens outside of your domain, where you can't instantly summon an engineer. If you tell me that you've been never affected by the network outage of your peering partner I will be greatly suprised.
>>
> +1
> 
> I would also point out this feature has been in deployment for at
> least five years in at least two hyperscalers-- there has been no
> major meltdown. We'll make the feature opt-in because we may be
> exposed to non-conformant devices in the network that make incorrect
> assumptions, but I have yet to see any convincing argument that we
> should remove the feature becauses it's fundamentally harmful or not
> providing benefits.

It breaks FL-based load-sharing.



> As for the mentality of "the network will fix the problem", that's
> obviously an easy statement to make from a router vendor point of
> view, but that luxury simply doesn't match the realities of how host
> stacks are implemented deployed at global scale.

Not sure what you mean. We rely on that for the current Internet (hosts 
do not do source-routing).



> This starts with the
> fact that there is no such thing as "the network"; Linux stack for
> instance needs to run on every network on Earth and I have no idea
> which of these networks provides adequate security, fault detection
> and repair, are well managed, or even have devices that conform to the
> standards (non-conformant network devices are common). The only
> recourse we, i.e. host side developers, have is to stick with the
> least common denominator in the general case, and allow optional, but
> still protocol conformant, features in limited use cases such as
> limited domains (hence why the flow label modulation feature should be
> optional as we've already established in this thread).

Modulo the comments I've already made, I'm afraid we might be in the 
path of making the FL unusable...

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1