Re: [v6ops] Flow Label Load Balancing

Fernando Gont <> Wed, 25 November 2020 07:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23A6C3A112D; Tue, 24 Nov 2020 23:13:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G6ejUeGjDEYm; Tue, 24 Nov 2020 23:13:35 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA0E03A1129; Tue, 24 Nov 2020 23:13:33 -0800 (PST)
Received: from [IPv6:2800:810:464:8164:dc8c:7589:8676:bd67] (unknown [IPv6:2800:810:464:8164:dc8c:7589:8676:bd67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 085AF28050F; Wed, 25 Nov 2020 07:13:28 +0000 (UTC)
To: Alexander Azimov <>
Cc: tcpm <>, IPv6 Operations <>
References: <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Wed, 25 Nov 2020 04:04:10 -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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [v6ops] Flow Label Load Balancing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Nov 2020 07:13:38 -0000

On 24/11/20 16:28, Alexander Azimov wrote:
> Hi Fernando,
> Stating that FL change during TCP session lifetime is a bug - is a bit 
> harsh.

Apologies if it came across like that -- the intent was to be blunt, 
rather than harsh.

> It is a fantastic idea to change the FL value if RTO or SYN_RTO happens 
> in a controlled environment.

As noted in my previous email, I'm not sure what you mean by RTO -- but 
if you really mean "retransmission timeout", doing that fails the 
definition of FL by RFC6437 and others. -- a retransmitted packet 
belongs to the ame flow, not to a different one.

That aside, please define "controlled environment". :-)

> These are very specific TCP timeouts, that provide enough guarantee that 
> there will be no out-of-order packets,

Strictly speaking, that's incorrect:: the RTO is an estimation, and may 
be fired incorrectly (although the whole point of measuring the RTT anc 
computing the RTO is for that case to be rather rare).

>  though your packets will reach 
> the destination even in case of an outage inside your network. Zero 
> influence on your services in case of the network outage - doesn't sound 
> like a bug for me.

It seems to me that this sort of behavior is the reason for which folks 
actually disable the use of the FL. (i.e., think what happens for load 

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1