Re: [Anima] ANIMA when there is a system-wide issue

Toerless Eckert <> Tue, 26 January 2021 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D983D3A0DAE for <>; Tue, 26 Jan 2021 11:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.25
X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pvFdUkcQ79lb for <>; Tue, 26 Jan 2021 11:18:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F42F3A0DBA for <>; Tue, 26 Jan 2021 11:17:52 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 55EB754804B; Tue, 26 Jan 2021 20:17:46 +0100 (CET)
Received: by (Postfix, from userid 10463) id 4D680440163; Tue, 26 Jan 2021 20:17:46 +0100 (CET)
Date: Tue, 26 Jan 2021 20:17:46 +0100
From: Toerless Eckert <>
To: Michael Richardson <>
Cc: Brian E Carpenter <>, Anima WG <>
Message-ID: <>
References: <> <29097.1606779376@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <29097.1606779376@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Anima] ANIMA when there is a system-wide issue
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jan 2021 19:18:22 -0000

On Mon, Nov 30, 2020 at 06:36:16PM -0500, Michael Richardson wrote:
> Brian E Carpenter <> wrote:
>     > Perhaps there is something we should specify in ANIMA to prevent the
>     > ANIMA infrastructure falling into this sort of trap: when there is a
>     > system-wide issue (such as hitting an O/S resource limit everywhere at
>     > the same time) it also prevents the autonomic mechanisms from working.
> I think you mean, that it should not also prevent the autonomic system?
> I think that key is:
>   1) allocate resources (including threads) up-front
>   2) do not dynamically allocate threads per interface, but rather use async
>     routines.

Reminds me of university times in the 80th. In my university, they had built
a network layer packet accounting system (midle box like the firewall, i let you guess the
network layer protocol). Using:

I took a semester programming PEARL. No dynamic resource management. Pain
in undisclosed body parts. But gets you into the mood to think about how
to handle fixed constraints.

Didn't help to avoid buggy software though. One month it claimed i had
used 60,000 German Marks in network resources. Turned out it was "only"
6,000 though. Programming bug related to insufficient testing with corner
situations (high numbers).

I thought Facebook praised itself by creating regularily
"A Series of Unfortunate Events" into its software to ensure the system
is continuously hardened.

> But, I don't know what we could write into the specification to make this
> happen.  It seems that we really just need smart implementers.

Unless there is documentation for what constitutes "smart", you can only count
on "experienced".  Oh wait: Networking is a commodity. "Experienced" is too
expensive for our industry.


> --
> Michael Richardson <>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide

> _______________________________________________
> Anima mailing list