Re: [Din] Updated charter proposal

Thomas Hardjono <> Fri, 13 July 2018 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 052C5130E01 for <>; Fri, 13 Jul 2018 08:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hqhJQNiRPEku for <>; Fri, 13 Jul 2018 08:55:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F19B130DF9 for <>; Fri, 13 Jul 2018 08:55:04 -0700 (PDT)
X-AuditID: 1209190d-167ff70000001680-94-5b48cb561165
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id FE.5D.05760.65BC84B5; Fri, 13 Jul 2018 11:55:02 -0400 (EDT)
Received: from (OUTGOING-EXCHANGE-3.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w6DFt0mQ024465; Fri, 13 Jul 2018 11:55:01 -0400
Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU []) by (8.13.8/8.12.4) with ESMTP id w6DFt5BF028889; Fri, 13 Jul 2018 11:55:12 -0400
Received: from ( by W92EXEDGE6.EXCHANGE.MIT.EDU ( with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 13 Jul 2018 11:54:54 -0400
Received: from ([]) by ([]) with mapi id 14.03.0352.000; Fri, 13 Jul 2018 11:54:57 -0400
From: Thomas Hardjono <>
To: Toerless Eckert <>, Paulo Mendes <>
CC: Melinda Shore <>, "" <>
Thread-Topic: [Din] Updated charter proposal
Thread-Index: AQHUFvsNJivzqRslkUGtC5+5xIPa/aSNJwSAgABsOID//8IYsA==
Date: Fri, 13 Jul 2018 15:54:56 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjm247b2fDIaU79vFaDSJpbZiH7ESEisiTDMPoxKT25k1tuR9mZ piImmBKWseYlXZGpGakhuX5MapXOLJwwtAuJJSZKF8PMG0nm6Jwdb/+e931uvHwfypes+oWh espMmijCIBOIEYkoSK44M6zOiL01Ga9qX3iOqOZb7wPVuoVSeT6u8RMQdVPPHFDX9gwI1L/u 1AvVK9euImmIRnxUSxr0haTp4LEssc49OiLM70sqWpsKLgeVqmogQiF+BI6/swurgRiV4G08 +PbTGOCGPgD/Dr/ZGF4D6PF08bjBAeB0Q/fG0AFghb2Jz4YJ8GhYtVrDhKGoFE+FDVYRu+bj GvjZ3unH4kBcDp11Kz65FI+BI801CIcTYV9rlW+P4PugpdvCY2MwPB3Wthu5KieAa55Kn0aE n4JV72cBiwEeDP+4H/G4rhA4PtPM427bBVtvO/kcDobep1MCDkdB52+HkNMr4Vh9nYDDcvig 5adPjzHeoaYZxAKgbUesbYfFtsNi22G5B5BOEKk1liiMhN5Ak9kKOpugKNKkiFMa9WYlqS2w A9+jhmK9wDuR4gI4CmT+2OMudYbEjyiki40uEIryZEFY/xNmFXA+T1usI2hdpqnAQNIuAFG+ TIoVXmc4TEsUl5CmvE0qHEVkIVhuK8iQ4DmEmcwlyXzStMlGoKgMYqSbMe4ykTlk0QW9wbxN 81ARG+7PhEuG2HA6nzDS+hyOdwMF+m++3sqXIFQeRYaFYJFsEM6KdAXUVo7vwwqPR8yCEOas QKyNVfkz33kraZYp4TEl57TJbImZ2KbCykHpD0fc0o3ZDxmNSrzUKm/MPFkSUOSKT42vFSc8 7KRLn01r5hYmDPWqVxeXv71In7w0bB34Lm2pyLInh+f2dvTsVuwx9i+VWAZjFyMrrlg1Se39 X6jE6DLX5PRX5d39jiE8be+onzdGneLJPns6WnbCEHX45uVFb/PEYNnL9eVcGULriEMH+Caa +A8V+LCliwMAAA==
Archived-At: <>
Subject: Re: [Din] Updated charter proposal
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Jul 2018 15:55:07 -0000

>>> Distributed/Decentralized:
>>> Unless there is well defined terminology to the contrary (please point me
>>> to an authoritative place if there is), 

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

-- thomas --

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

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).

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


On Fri, Jul 13, 2018 at 10:07:45AM +0100, Paulo Mendes wrote:
> 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 (
> Director of NEMPS PhD program ( <>)
> Associated Professor at University Lusofona, Portugal
> <>
> Tel: +351 217 50 50 22
> > On 08 Jul 2018, at 21:34, Melinda Shore <> wrote:
> >
> > 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
> >
> > --
> > Software longa, hardware brevis
> >
> > PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
> >                 34C0 DFB8 9172 9A76 DB8F
> >
> > _______________________________________________
> > Din mailing list
> >
> >

> _______________________________________________
> Din mailing list


Din mailing list