Re: [Din] Updated charter proposal

["Diego R. Lopez" <[e-mail]>]

 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: [e-mail]
Tel:         [phone]
Mobile:  [phone]
----------------------------------

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

    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]

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



________________________________

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