Re: [Din] Updated charter proposal

Toerless Eckert <tte@cs.fau.de> Sat, 14 July 2018 22:11 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4112130F1B for <din@ietfa.amsl.com>; Sat, 14 Jul 2018 15:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] 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 qtB40Cq9xAjy for <din@ietfa.amsl.com>; Sat, 14 Jul 2018 15:11:16 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C7F130F16 for <din@irtf.org>; Sat, 14 Jul 2018 15:11:16 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3F5DA58C4AF; Sun, 15 Jul 2018 00:11:12 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2E49E4402CB; Sun, 15 Jul 2018 00:11:12 +0200 (CEST)
Date: Sun, 15 Jul 2018 00:11:12 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Melinda Shore <melinda.shore@nomountain.net>
Cc: "din@irtf.org" <din@irtf.org>
Message-ID: <20180714221111.5bshkw6ucr3pf6zn@faui48f.informatik.uni-erlangen.de>
References: <76cd5da5-c2ba-dc04-e1bb-6ffd49f94eb3@nomountain.net> <D56BEA89-1EDA-47C1-8072-102DB2B1361A@ulusofona.pt> <20180713153505.csx5ih4g3ynhsrkk@faui48f.informatik.uni-erlangen.de> <A397738A-7F2D-43D8-9914-E85ABC40A40A@telefonica.com> <41aad02d-2b9a-e0a3-b8ee-b4760bf6d4a3@nomountain.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41aad02d-2b9a-e0a3-b8ee-b4760bf6d4a3@nomountain.net>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/o7g7YNLdjkWp2yBEsQxtzG8bCLw>
Subject: Re: [Din] Updated charter proposal
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/din>, <mailto:din-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din/>
List-Post: <mailto:din@irtf.org>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/din>, <mailto:din-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jul 2018 22:11:19 -0000

Inline
On Sat, Jul 14, 2018 at 03:07:29PM -0400, Melinda Shore wrote:
> I'm not sure it's helpful to consider "decentralized" and "distributed"
> as having a subsetted relationship (in either direction).  It may be
> helpful to be more explicit about what's meant by "decentralized" in the
> dinrg context, especially since we're seeing some proposals which may
> or may not be considered decentralized depending on definition and
> scope.
$
Melinda,

A) For technical curiosity: Can you give me an example of something
that you consider to be distributed but not decentralized ? (i can
think of answers, but not sure what you think)

B) IMHO, you do not want to waste cycles now on working out a comprehensive
definition/ terminology/taxonomy, when it seems clear that this is rather
complex and that the RG would be able to come up with better results
after having done more work.

Calling distributed a subset of decentralized was not meant to be the
ultimate definition. Its just the most simple definition for two goals:

  I) Avoids having to always write Decentralized/Distributed everywhere. 

  II) Make it clear that the RG does not assume any more specific definitions
  now, so the ball is in the court of any author to be precise about any
  specific aspect of decentralization/distribution that their document
  assumes.
  
If the WG does not make any default definition of these terms, DINRG
could simply run into the same problems ANIMA ran into with the word "Intent".
We had drafts where different authors of the same document assumed the term 
to mean something different.

C) i would suggest not to mention/discuss "centralized" at all adn
try to position DINRG vs. centralized:

The RG should exclude work because its "centralized only" on a case-by-case
basis and not try to constrain itself in the carter artificially.
I think everybody including charter approvers will have a hard time
to come up with a good agreeable definition of "centralized". 
As in: How many meters/miles do the CPU cores in my data center need
to be apart from each before you allow me to call it decentraliced/distributed ?

KISS.

D) > Vitalik proposes three characteristics:
>
> .. architectural decentralization (number of entities in the network),

I have a router, it consists of a entities called linecards
and fabric cards.  How large does it need to be to be in scope ? A 
candidate router in 2000 was planned to have one ethernet port to every
resident of Chicago.

DO need to call my router a network so that it would be in scope ?
Does it have an impact if i expose the decentral nature at the management
level (configure per decentralized entity), is there a minimum number
of entities to make something in/out of scope for DINRG ?

Aka: A coarse criteria does not make a good metric and even less so
a useful threshold.

> .. political decentralization (control/policy), and

Its a nice aspect for classification/taxonomy, but not a good
metric/threshold for work inside/outside of DINRG.

Any intradomain technology like IGPs would not have that political
decentralizated for example but shuld be in scope for DINRG.

We also should not come up with "<foobar> decentralized" terminology
unnecessarily if there are already better technical words (intra/interdomain)

> .. logical decentralization

As opposed to illogical decentralization ? Not clear what this means.

> with the latter being somewhat problematic, in that at some point you
> probably want consistent state across all participants (i.e. you
> should be able to continue if there's a partition, but then eventually
> converge).

I am not sure how what you say is related to "logigal decentralized",
i would see it equally true or false for "physcial decentralization".

Instead of consistency, i rather think the degree of supportable
inconsistencies is a possible metric for decentralization. In 
interdomain routing we only consistency requirement is to have no persistant
loops.  Everything else can be inconsistent (ignoring other constraints). 

But: In summary: definitions/classifications/metrics/thresholds/taxonomy is
hard work. Maybe a good topic for the WG, but not for the charter.

> I'm not sure I agree with this framing but it may be a useful starting
> point for discussion.

E) Well, as said, i would suggest not to frame the treminology more
than minimum necessary for the charter. 

But if/when we have a framing/terminology discussion:

I like "non-uniformity" / "Heterogenity". IMHO, its the most encompassing
characeristics for DINRG IMHO because it can include all those aspects
  - independent failure of components
  - partical connectivity between components
  - partitioning
  - functional decomposition
  - differences in communications channels 
  - differences in compute / storage component capabilities

Cheers
   Toerless

> 
> Melinda
> 
> -- 
> Software longa, hardware brevis
> 
> PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
>                      34C0 DFB8 9172 9A76 DB8F