Subject: [Din] Updated charter proposal

From: Melinda Shore <[email-masked]>
Date: Sun, 8 Jul 2018 12:34:08 -0800

Hi, all:

We've updated the proposed charter based on discussions we've
had with participants over the past several weeks, and we're
looking for additional feedback.  Please take a look and send
comments to the mailing list.  As I think most of you know,
proposed research groups may meet for a year before a decision
is made to charter them, or not, and we will be at the one-year
mark in Montreal.  We want to make sure the charter text
reflects the direction we'd like to take and the work we'd
intend to undertake once chartered.

The current draft is at:
https://docs.google.com/document/d/17V6dAawxdda_oiul3p1ssRDYSlHFOe9CnXn-4iLTCdI/edit?usp=sharing

Many thanks,

Melinda & Dirk

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
                 34C0 DFB8 9172 9A76 DB8F

---

From: Mats Wichmann <[email-masked]>
Date: Sun, 08 Jul 2018 15:24:05 -0600

the paragraph under Research Challenges is not making much sense as written... there is at least an extra "intensive", and the contrast "less attention, despite" doesn't really click either.

On July 8, 2018 2:34:08 PM MDT, Melinda Shore <[email-masked]> wrote:
>_______________________________________________
>Din mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/din

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: "Weixinpeng (Jackie)" <[email-masked]>
Date: Mon, 9 Jul 2018 06:51:59 +0000

Hi Melinda & Dirk,
Thanks for your effort on the new charter proposal. Here my two comments about the new charter:
1.The deliverables are not mentioned, so currently is there any plan for the deliverables?
2.In the Research Challenge section, a new entry "Disambiguation in decentralized naming and trust systems" is added, it seems not quite clear to me how to interpret it, so is there any
background for adding this entry?

Thanks!
Regards,
-Xinpeng
-----Original Message-----
From: Din [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Monday, July 09, 2018 4:34 AM
To: [email-masked]
Subject: [Din] Updated charter proposal

Hi, all:

We've updated the proposed charter based on discussions we've had with participants over the past several weeks, and we're looking for additional feedback.  Please take a look and send comments to the mailing list.  As I think most of you know, proposed research groups may meet for a year before a decision is made to charter them, or not, and we will be at the one-year mark in Montreal.  We want to make sure the charter text reflects the direction we'd like to take and the work we'd intend to undertake once chartered.

The current draft is at:

Many thanks,

Melinda & Dirk

---

From: David Mazieres <[email-masked]>
Date: Mon, 09 Jul 2018 00:35:13 -0700

> https://docs.google.com/document/d/17V6dAawxdda_oiul3p1ssRDYSlHFOe9CnXn-4iLTCdI/edit?usp=sharing

Thanks for the work you put into this.  A few comments:

        The focus of DINRG is on infrastructure services that can
        benefit from decentralization or that are difficult to realize
        in local, potentially connectivity-constrained networks.

Some of the naming and trust issues would seem to fall under this focus
only indirectly.  Yes, they are difficult to realize locally because you
don't fully trust any local environment.  But as read, it sounds like
the main limitation of local is that it's potentially connectivity
constrained, while that is only one of several issued.

        Some of the increase in centralization is due to business
        models that rely on centralized accounting and administration,
        but there are also cases where centralization is the result of
        hierarchical trust models which rely on "trusted third
        parties.".

But isn't a big hypothesis here that some of the increase is due neither
to business models nor to inherent hierarchical trust, but rather just
to missing infrastructure?  A kind of dumb but hugely impactful example
would be the use of cloud services where you don't need huge data or
aggregation over many users, but just because NAT traversal and dynamic
IP addresses are a pain.  An example closer to the working group would
be HSTS preload lists maintained in a centralized fashion by the browser
vendors, simply because there's not a good Internet infrastructure for
web site operators to construct these lists in a decentralized fashion.

        regular several physical meetings per year.

Probably mean "several regular"

David

---

From: Paulo Mendes <[email-masked]>
Date: Fri, 13 Jul 2018 10:07:45 +0100

Hi Melinda,

Were are my 2cents about the charter:

a) Since the charter is focused on *network services* it would be good to enumerate some services that really depend on a decentralised operation. I can deploy a trust management or identity management mechanism based on a centralised service. It is true that decentralising such services may increase their performance, but that would diminish the proposed of the charter towards “only” network optimisation issues. To make the charter stronger I would suggest to clear identity services that really require a decentralised/distributed infrastructure to operate, and those that although can be deployed in a centralised manner, gain a lot (e.g. in terms of performance) from the decentralised / distributed network operation. IMO, the services mentioned in the charter fit the latter case. I would say that examples of services that really require decentralised / distirbuted are: fog and edge computing (at least they require a decentralised approach, which fog arch pointing to the need for cooperation among fog devices); intermittent connect networks (in this case all the services mentioned in the charter must be decentralised / distributed); Data privacy (from the centralised silos to personal clouds); Network automation (which requires network devices to be more autonomous); Distributed ledge technology. In the latter case I agree in stating that this is not the only case, due to the current hype.

b) Besides the mentioned technical use-cases / services, the charter should highlight that DINRG is aware that decentralising / distributing requires a set of core drivers: trust, incentives (may be technical or economic) and consensus. At least those were the ones that I mentioned in the London meeting. IMO, it will not be possible to build decentralised / distributed services if involved peers do not trust each other, have no incentives to cooperate and have no basic mechanism to reach consensus to solve conflicting operations.

c) The name of the research group mention “Decentralised” but the charter mention decentralisation as well as distribution, which are different things. So, a may doubt is if the charter will limite the work to decentralisation aspects, or if it will also tackle distributed services.

e) As for the motivation, the question is how DINRG will contribute the revert the centralisation of the network operation, as is the case of Network Cloudification, which goal is to centralize and virtualize networking into data centers. This can actually be a good use-case: to show that CAPEX and OPEX can be reduced relaying in a full distributed approach (e.g. deployed at network edges) instead of relying on data centres (which of course can be seen as a distributed computing system :-) ).

As for the interface with other IETF/IRTF groups, I would include NMRG. The work with other groups should be useful to keep DINRG focused on the its core objectives.

As for the Objectives it may be difficult for a RG to operate actual implementations, although I agree that it should be the responsibility of any RG to demonstrate that proposed solutions work, by working on proof-of-concepts (before going to IETF). Besides this I would like to see the following objectives:
- Bring attention of the scientific community to DIN issues and challenges by organising workshops, tutorials, international conferences.
- Describe the use-case that really need decentralisation to be deployed, and the use-cases that rely in decentralisation for a better performance.
- Specify the drivers for DIN, without which decentralisation is not possible.
- Clearly create task-forces (commitment) in order to reach a set of proof-of-concepts. I know that IETF is a self-organised organisation :), but sometimes we need push models :) to go beyond what is expected from a RG.

Melhores Cumprimentos / Best Regards / Mit freundlichen Grüßen
------------------------------------------------
Paulo Mendes, Ph.D
Coordinator SITI group @ COPELABS (http://siti.ulusofona.pt)
Director of NEMPS PhD program (http://nemps.ulusofona.pt <http://nemps.ulusofona.pt/>)
Associated Professor at University Lusofona, Portugal

http://www.paulomilheiromendes.com <http://www.paulomilheiromendes.com/>
Tel: +351 217 50 50 22

> On 08 Jul 2018, at 21:34, Melinda Shore <[email-masked]> wrote:
> 
> Hi, all:
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 13 Jul 2018 17:35:05 +0200

Great points Paulo

Let me also add some: 

Nomadic connectivity:
Use instead of "intermittent connectivity".  IMHO actually a likely
interesting area for DINRG also because AFAIK, 5/6G introduces lightweight
IoT UE profiles without seamless mobility (so the network can support an
order of magnitude more UE/cell).

Distributed/Decentralized:
Unless there is well defined terminology to the contrary (please point me
to an authoritative place if there is), i would make up our own definition,
and that is that distributed is a subset of decentralized. That would allow
to use a single word (decentralized) without excluding the other. Include
note to that effect somewhere (charter etc..).

Geographically dispersed and heterogenuous:
Cloud native DC apps today can often be characterized as consisting
of multiple roles. Each role has one or more active instances for
load-sharing (often called leaders). These are backed by followers
in standby with whom state is shared  so they can take over. And
when instances fail, new ones are restarted to maintain resilience.

So, what DINRG should want to think about is then what is untraditional for
DC: The heterogenity of possible instances, geographic distrbution
of instances and the resulting delay and thoughput limitations between
instances, but gained throughput/delay to clients, and geographic placement
for resilience, etc. pp.

Note that DCs of course start to think about these things to, because
the DC likely will become of of a microcosmos of WAN networks. YOu
will have more and more compartmentalized connetivity, so you can not
schedule instances arbitrarily and hope there is no network bottleneck
then, you also will have more specialized resources not available
on every node (NN/AI, GPU, CPU, maybe even NPU) and schedule accordingly.
Heck, you may want to schedule based on security (to avoid side-channels)
Thats fine. Any advanced solution that include these complex aspects of
heterogenity should be interesting forr DINRG. It doesn't have to be WAN,
but of course WAN is likely the ultimate challenge to meet for many
problems.

Cheers
    Toerless

On Fri, Jul 13, 2018 at 10:07:45AM +0100, Paulo Mendes wrote:
> a) Since the charter is focused on *network services* it would be good to enumerate some services that really depend on a decentralised operation. I can deploy a trust management or identity management mechanism based on a centralised service. It is true that decentralising such services may increase their performance, but that would diminish the proposed of the charter towards ???only??? network optimisation issues. To make the charter stronger I would suggest to clear identity services that really require a decentralised/distributed infrastructure to operate, and those that although can be deployed in a centralised manner, gain a lot (e.g. in terms of performance) from the decentralised / distributed network operation. IMO, the services mentioned in the charter fit the latter case. I would say that examples of services that really require decentralised / distirbuted are: fog and edge computing (at least they require a decentralised approach, which fog arch pointing to the need for cooperation among fog devices); intermittent connect networks (in this case all the services mentioned in the charter must be decentralised / distributed); Data privacy (from the centralised silos to personal clouds); Network automation (which requires network devices to be more autonomous); Distributed ledge technology. In the latter case I agree in stating that this is not the only case, due to the current hype.
> 
> c) The name of the research group mention ???Decentralised??? but the charter mention decentralisation as well as distribution, which are different things. So, a may doubt is if the charter will limite the work to decentralisation aspects, or if it will also tackle distributed services.
> 

-- 
---
[email-masked]

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 13 Jul 2018 15:54:56 +0000

>>> to an authoritative place if there is), 

I'd suggest just using the glossary in the recent NIST draft:

https://csrc.nist.gov/publications/detail/nistir/8202/draft

-- thomas --

________________________________________
From: Din [[email-masked]] on behalf of Toerless Eckert [[email-masked]]
Sent: Friday, July 13, 2018 11:35 AM
To: Paulo Mendes
Cc: Melinda Shore; [email-masked]
Subject: Re: [Din] Updated charter proposal

Great points Paulo

Let me also add some:

Nomadic connectivity:

Cheers
    Toerless

--
---
[email-masked]

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sat, 14 Jul 2018 01:24:50 +0000

I would object to consider distributed a subset of decentralized. I can imagine distributed systems that are centralized: think of a PKI with a root CA and several sub-Cas at several levels... So I'd prefer to keep the D standing for distributed.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 13/07/2018, 16:35, "Din on behalf of Toerless Eckert" <[email-masked] on behalf of [email-masked]> wrote:

    Great points Paulo

    Let me also add some:

    Nomadic connectivity:

    Cheers
        Toerless

    --
    ---
    [email-masked]

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Melinda Shore <[email-masked]>
Date: Sat, 14 Jul 2018 15:07:29 -0400

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.

Vitalik proposes three characteristics:

. architectural decentralization (number of entities in the network),
. political decentralization (control/policy), and
. logical decentralization

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'm not sure I agree with this framing but it may be a useful starting
point for discussion.

Melinda

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 15 Jul 2018 00:11:12 +0200

Inline
> or may not be considered decentralized depending on definition and
$
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.

> should be able to continue if there's a partition, but then eventually

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

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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 14 Jul 2018 18:20:19 -0400

CDNs are a textbook example of a widely distributed system with highly centralized control.

Grüße, Carsten

> On Jul 14, 2018, at 18:11, Toerless Eckert <[email-masked]> wrote:
> 
> distributed but not decentralized

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 14 Jul 2018 17:25:54 -0500

How about generalizing it to any protocol or architecture where you cannot communicate at the app level when you have IP connectivity and not Internet connectivity. 

Dino

> On Jul 14, 2018, at 5:20 PM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 15 Jul 2018 01:10:40 +0200

You are comparing a system (CDN) with one of its aspect (control),
that was not the question.

Would you call the overall CDN non-decentralized, and if so, why ?

Sure, you can try to come up with different characteristics of a system
that impact whether you call them distributed vs. decentralized, but
i don't think you will do the charter a favour if that type of definitions
needs to be agreed upon before passing the charter.

Cheers
    Teorless

---

From: Melinda Shore <[email-masked]>
Date: Sat, 14 Jul 2018 20:35:40 -0400

> that was not the question.

Well, I don't know - it might have been.  I think it's possible
to look at a number of different axes, including the question of
centralized control (which, come to think of it, strikes me
as one of the more significant aspects).

At any rate I think the question here is not to nail down a
precise definition, but rather to get a basic handle on what
is and is not in scope for the research group.  I think that
based on the original intent and on recent discussions, for
example, something along the lines of a traditional distributed
system like Amoeba would not be in scope, nor would technology
based on a permissioned blockchain, since both have highly
centralized control.  Similarly, someone might ask why we're
interested in alternatives to the DNS, which is distributed
but hierarchical and rooted in a small number of points of
control (allowing for the possibility of alternative hierarchies.

Melinda

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 15 Jul 2018 03:40:15 +0200

> as one of the more significant aspects).

Sure, but the question was about the relationship between
distributed and decentralized for a single object/entity and
not comparing two different things, even if one is the superset of another.

> is and is not in scope for the research group.

Right. And i was meaning to imply that we may simply want to establissh
the language notation that whenever we say "decentralized" we
mean "decentralized and/or distributed". Just to keep the langaage simple.

> I think that based on the original intent and on recent discussions, for
> based on a permissioned blockchain,

>  ... since both have highly interested in alternatives to the DNS...

I can not parse this.  Can explain this a bit more ?

> which is distributed
> control.

Many blockchains are now also built hierarchical, and you can easily
add a distributed consensus mechanism to protect against an
attack against less than 50% of DNS root servers. 

I think you'll have a very hard time to define crisp criteria for
in/out of DINRG this way. Probably a lot easier to just stick to
the classical approach of figuring out what the top interest of
the RG contributors is, how many they can work on in parallel
and avoiding to step on other RGs feet. ;-)

> (allowing for the possibility of alternative hierarchies.

Alternative hierarchies are not a good thing to you ? 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Christian.Hoeppler <[email-masked]>
Date: Sun, 15 Jul 2018 03:58:08 +0200

> Would you call the overall CDN non-decentralized, and if so, why ?

Well, I'd not call it decentralized, if an essential aspect or subsystem
is highly centralized.

Cf. https://news.earn.com/quantifying-decentralization-e39db233c28e for
an approach how decentralization may be quantified.

Best,
Chris

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 15 Jul 2018 06:20:07 +0200

> Well, I'd not call it decentralized, if an essential aspect or subsystem

So you would call a composite system distributd if _SOME_ aspects
are decentralized, and decentralized if _ALL_ aspects are decentralized ?

Aka: i think this is all dfficult and will take a long time to agree on,
so bad idea trying to define scope of charter on such ambiguously interpreted
terms.

> an approach how decentralization may be quantified.

Nice, thanks. And blockchains are simple systems composed from few
functions with little structure (compared to a typical network and
all its L2..L9 functions).

Cheers
    Toerless

---

From: Niels ten Oever <[email-masked]>
Date: Sun, 15 Jul 2018 18:17:26 +0200

In the discussion on distirbution vs centralization this article might
be of interest:

https://policyreview.info/articles/analysis/myth-decentralised-internet

Abstract
In popular culture, and in policy discussions, the internet is often
conceived of as a decentralised technology, which cannot be controlled.
Drawing from research into internet infrastructure, focusing on the
Border Gateway Protocol, I show that the internet has never been, and
never can be, decentralised. I argue that the internet is better viewed
as being distributed, both in terms of technologies and governance
arrangements. The shift in perspective, from decentralised to
distributed, is essential to understand the past and present internet,
and to imagine possible future internets which preserve and support the
public good.

RFC8280 proposes:

   Decentralized:  Implementation or deployment of standards, protocols,
      or systems without one single point of control.

Best,

Niels
-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488
                   643A 0ED8 3F3A 468A C8B3

---

From: Melinda Shore <[email-masked]>
Date: Sun, 15 Jul 2018 12:28:46 -0400

On 7/15/18 12:17 PM, Niels ten Oever wrote:>
https://policyreview.info/articles/analysis/myth-decentralised-internet
I think that's useful but I'll note that the word "layer"
does not appear anywhere in the article, and there's no
mention of work on ad hoc networks, which have been standardized
in the IETF and are therefore arguably part of "the internet."
Anyway, while IP-based protocols are not layered as cleanly as
one might like, it's typically the case that when we consider
the design of infrastructure services, like naming or trust,
we rarely consider the interaction with routing and so on.

Anyway, I think that what the author is arguing is basically
consistent with how we see the internet in general, which is part
of what motivates this work on decentralizing internet infrastructure.
We don't currently have decentralized services - there are points
of centralized control in today's internet - but we're interested
in how they can be built and function on top of IP-based protocols.

Thanks for the pointer!

Melinda