Re: [v6ops] Flow Label Load Balancing

Fernando Gont <> Sat, 28 November 2020 03:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C93B83A0DEA; Fri, 27 Nov 2020 19:50:24 -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 Eb-n3T9NpCMH; Fri, 27 Nov 2020 19:50:21 -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 8F6843A0DE8; Fri, 27 Nov 2020 19:50:12 -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 (Postfix) with ESMTPSA id B7F0D2845F1; Sat, 28 Nov 2020 03:50:08 +0000 (UTC)
To: Tom Herbert <>
Cc: Alexander Azimov <>, tcpm <>, IPv6 Operations <>
References: <> <> <> <> <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Sat, 28 Nov 2020 00:49:52 -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: 7bit
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: Sat, 28 Nov 2020 03:50:25 -0000

On 27/11/20 20:31, Tom Herbert wrote:
> All we know in this case is that *TCP* has detected a connection is
> failing and there may be a potential problem with a path, we don't
> know that the network has detected any problems like some link is
> failing or will ever detect any problem. So in such a scenario, what
> recourse does the host have to try to salvage its connections?


TCP times out and restransmits. And *the network* routes around failing 

> If the
> answer is that the host should always patiently wait for the network
> to figure out what is happening, then that's going to be a hard sell
> to application and host stack developers (remember the network is a
> black box from their perspective that they really don't trust).

Either that, of you switch to a different destination address if the 
transport protocol allows.

> If the
> answer is that the host is supposed to inform the network of issues
> with it's connections and then host and network work together to solve
> then that's great; 

The only thing the host can do is to switch to a different transport 
protocol if it allows.

> but then what is the general protocol that has been
> established to facilitate that and solved the problem of how hosts and
> network work together in concert to solve user's problems?

They don't really work together (modulo congestion control, one might 
argue), but rther complement each other (TCP times out and retransmits, 
and the network routes around failing paths).

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