Re: [v6ops] Flow Label Load Balancing

Fernando Gont <fernando@gont.com.ar> Fri, 27 November 2020 20:52 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 A6B083A0E8B; Fri, 27 Nov 2020 12:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 w4JRSMgJeH_P; Fri, 27 Nov 2020 12:52:24 -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 6AB773A0DB2; Fri, 27 Nov 2020 12:52:24 -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 5DB63283BC9; Fri, 27 Nov 2020 20:52:21 +0000 (UTC)
To: Alexander Azimov <a.e.azimov@gmail.com>, Tom Herbert <tom@herbertland.com>
Cc: 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> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> <CALx6S34uSAne_LyhrWDcjkR5p7MO6ggm_Ua_h+6nkX41S=Ge=A@mail.gmail.com> <a8aad80c-1a4b-4a86-4c13-7391e8513049@joelhalpern.com> <CALx6S36xYADqNrPp1A_Ohx48d7SdV2oFOgVFVV+y_tDbGQG6ug@mail.gmail.com> <abf9c63a-2f7e-6f28-34e8-b3e9598cd2b9@gmail.com> <CALx6S36PTVT49CQHdJNx88PHyYQS23WYP3A7Xw1-+f_tt4H3Gg@mail.gmail.com> <CAEGSd=BGqFTygTiAt1v-71W3RTpdyVqyYzD1vi9uKebPPMoE5Q@mail.gmail.com>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <5cb3b43e-913f-d6cd-f7e2-192f14daf4c2@gont.com.ar>
Date: Fri, 27 Nov 2020 17:52:14 -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: <CAEGSd=BGqFTygTiAt1v-71W3RTpdyVqyYzD1vi9uKebPPMoE5Q@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/uGhFP9mPTkG6_ZXLegCY9YInsKw>
Subject: Re: [v6ops] 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: Fri, 27 Nov 2020 20:52:27 -0000

On 26/11/20 06:34, Alexander Azimov wrote:
> Dear colleagues,
> 
> We started discussing an incorrect default behavior, and Tom has already 
> confirmed that it will be fixed.
> 
> Later the thread turned into an argument if the flow label can be 
> changed during connection/flow lifetime according to current RFC 
> documents, though these documents can be updated. This looks a bit weird 
> for me because I always thought that it is the IETF community's 
> responsibility to document proper solutions. If something undocumented 
> but worthy happens in the industry - IETF should catch up. So, I would 
> like to get back to the discussion of reasons and their safety.
> 
> The general idea of changing the routing path upon network 
> outage/degradation looks obvious. Getting kind of source-based routing 
> can significantly reduce the reaction time and improve end-user 
> experience. The flow label has a perfect match here: transparent for the 
> application, set by the source, not part of 5-tuple, while it can be 
> used in the load balancing. 

If you have two links, then, upon change of the FL, you have 50% change 
that the path will be different -- not good.  What would you do if the 
failure continues? -- keep changing the FL?



> Let say that the flow label is a hash of values from the IP packet's 
> 5-tuple and random number. Then
> 
> 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be 
> recalculated.

This one MUST be switched of by default, too. (along with #2).


> 2. In the case of RTO timeout expiration in the established TCP session 
> the flow label MAY be recalculated. This setting MUST be switched off by 
> default.
> 3. Otherwise flow label SHOULD be preserved unchanged.
> 
> The first point stands for redirecting connection from the degraded path 
> before the connection is established, and it looks safe. The second one 
> can also improve performance if it is set on the server-side. Please 
> comment if you see security flaws in such a design.

At the very least, one should analyze the case where in #1, a packet 
gets delayed, you change the FL and retransmit, and finally you get a 
response to the original packet (and/or to both packets).

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