Re: [Din] Updated charter proposal

[Toerless Eckert <[e-mail]>]

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:
> 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: [phone]
> 
> > On 08 Jul 2018, at 21:34, Melinda Shore <[e-mail]> 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:
> > 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
> > 
> > _______________________________________________
> > Din mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/din
> 

> _______________________________________________
> Din mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/din


-- 
---
[e-mail]