Re: [Coin] COIN activities update

Xavier de Foy <x.defoy.ietf@gmail.com> Fri, 13 November 2020 20:36 UTC

Return-Path: <x.defoy.ietf@gmail.com>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEA53A0991 for <coin@ietfa.amsl.com>; Fri, 13 Nov 2020 12:36:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jce5yaalYdKM for <coin@ietfa.amsl.com>; Fri, 13 Nov 2020 12:36:24 -0800 (PST)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9278A3A098D for <coin@irtf.org>; Fri, 13 Nov 2020 12:36:24 -0800 (PST)
Received: by mail-pl1-x633.google.com with SMTP id k7so5106836plk.3 for <coin@irtf.org>; Fri, 13 Nov 2020 12:36:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TiTOQ8GcBn8UQ34zTTQAkyeTgM17Iab7qG/7h1cVQno=; b=WghJ3dUTXJ5ySJ4GyXzRFF3ezfO0/s2XTWPThLqX67oXi4MJmakTiC/y2J8TUt5ta5 89xlt6fBid0VMdW07zv9yEdt+R8QZV90TIOCQiAtRMAezebr+KCVffmxSzR8Ktdywkrz 22rOW9cQQodaElFUs6OzD3nq9E6u0Z7jdc4PtU06ZavamiLQbzlrLkqsik/Dc+p8BDiB lb2NfiiZ2q7nW3uHlo3D7JQsjOxnsO4Mksg9iibO25lIfzIbzGBheoldtOp29/PgzCgY L6n3zv4qPrjvJQfbbOudEyj06X0h+itvSz9xnkM1++20rooXkh8VRwhtuE1B66CalgVR zaew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TiTOQ8GcBn8UQ34zTTQAkyeTgM17Iab7qG/7h1cVQno=; b=HWt3JoL36v0PKz1S7VMcVSk7+Fib936u++1hs5ntc7oElvJn1HNLdvU22RZzmceT9K EhbtHfaaqgnGsIunq3OctkBVBqE6Q9otrFQ9MbTiHhFgVOwHMnWJqVIVEfFKWHwfnchl 4qn2QYippOutotmb1MHhjOMrw0m2gWtI6xv1R5mTG4K52iZB2qKbAyG0wi5jTFq9d/lf nAmaLX5l/TBPg1gwn03dWvrrvnaJ/qzzOxyJuQdeg0tWQlT/qOsee40UbK+22NLa1AT8 6rhAKxnrEMYSzkt7kIywQayQO0tNJo/DfWzVK0vVemJgrsaQ4gEa/X+GcHoIDzGu60CT F70g==
X-Gm-Message-State: AOAM532bU9r+WKChudHWyoZY1ZmZuVOIMzzi1WCHSLjG2UxYjQfAgC/f W9rHS2jcHhcxRL8Q8HzxP4WhbkcYL9VcQJ2TCdE=
X-Google-Smtp-Source: ABdhPJypSxnD2UpZ3lOD/AT5/Uvo9dLcpN8h/3yf6NzfO11Isdw6FARxOHY5UdbiZquoEta37fDDYi7cPUU1RR77lYs=
X-Received: by 2002:a17:902:aa06:b029:d8:bc5b:612b with SMTP id be6-20020a170902aa06b02900d8bc5b612bmr3574789plb.50.1605299783925; Fri, 13 Nov 2020 12:36:23 -0800 (PST)
MIME-Version: 1.0
References: <CAPjWiCTXPc4uDBjcBpbnX7ruuDf_tnt3mo=uzpPOL5Z9PZVUQw@mail.gmail.com> <CAHYjOTb_KLy0zU+TFBivvFueNFZ=-X_24jH=Hb_MZta8Sp91YQ@mail.gmail.com> <PR3PR07MB682651D187EF8790EE010A2DF3170@PR3PR07MB6826.eurprd07.prod.outlook.com> <CAHYjOTZr2Zr2bHkZstA7AgZoZ-7-e+Na-D2_f6ADHkXqAC2pmQ@mail.gmail.com> <CAPjWiCRr93mEA3Zk0JEjznU=vvNk46RbG08DSV-eX-K34C1U6g@mail.gmail.com>
In-Reply-To: <CAPjWiCRr93mEA3Zk0JEjznU=vvNk46RbG08DSV-eX-K34C1U6g@mail.gmail.com>
From: Xavier de Foy <x.defoy.ietf@gmail.com>
Date: Fri, 13 Nov 2020 15:36:12 -0500
Message-ID: <CAHYjOTb1vo8XbLW2r+Ea1YLMJ8VQ1c1VuNoZSznr40Hr5h3yoQ@mail.gmail.com>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>
Cc: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <laurent.ciavaglia@nokia.com>, "coin@irtf.org" <coin@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000061045105b402fbad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/jruaYM1DmzyvsubRSrvMvzFLJwE>
Subject: Re: [Coin] COIN activities update
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2020 20:36:27 -0000

Thanks Marie-José, sorry for the delayed reply. I am looking forward to the
discussion in IETF 109 on this subject.

On Tue, Nov 3, 2020 at 8:19 AM Marie-Jose Montpetit <marie@mjmontpetit.com>
wrote:

> Since I was involved in some discussion with Xavier let me chime below.
>
>
>
> Marie-José Montpetit, Ph.D.
> marie@mjmontpetit.com
>
>
>
> On October 28, 2020 at 10:58:36 PM, Xavier de Foy (x.defoy.ietf@gmail.com)
> wrote:
>
> Hi Laurent,
>
>   Thank you for bringing up those questions.
>
> On Wed, Oct 28, 2020 at 4:02 AM Ciavaglia, Laurent (Nokia -
> FR/Paris-Saclay) <laurent.ciavaglia@nokia.com> wrote:
>
> Hi Xavier, all,
>>
>>
>>
>> Apologies if my comments are out of scope as I'm not so up-to-date with
>> the status of COIN technical work / terminology.
>>
>>
>>
>> I think the examples you gave makes sense and could be useful to clarify
>> of how various operations/flows could work.
>>
>
> The original discussion related to what’s “mobile" in the mobile data
> discovery and how does it relate to COIN. And since there is currently some
> work on Computing in the Network as it relates to 5G the discussion evolved
> from there I suppose hence the nomenclature used below.
>
>
>>
>>
>> Two comments:
>>
>>    1. What strikes me when reading the text is the reference to "COIN
>>    node" and "COIN network". Are these really necessary/useful terms
>>
>>
>
> To give some context, a discussion on whether discovery is within the
> scope of COIN was started in IETF 108 and never resolved. This email was an
> attempt to move this forward. The scenarios were my interpretation of how
> (data/resource/service) discovery would be used in the context of COIN.
>
> I actually think that we could think of a COIN-enabled node that could be
> discovered (mobile or not) but I agree that a "COIN network” is frankly
> just a network unless we consider only those nodes that are associated with
> computing capabilities and that a COIN network is established post
> discovery with the goal of orchestration or capabilities sharing. Xavier:
> is this what you had in mind?
>
Yes, thanks for clarifying this.

>
>
>
>> I mean, I could map the examples you describe (partially or fully) to
>> different existing technologies/operations. I find that adding the "COIN
>> stuff" may shift the focus away from the genuine technical problem to solve
>> by giving a false impression that the "COIN xyz" are sketching a different
>> case. Reading your examples without the COIN-related terms, the sentences
>> are still very valid. So, I guess the technical problem/solution to address
>> is situated at another level, i.e. what is not working as you expect it or
>> what would like to enable (in a COIN-like framework) that would be (solved)
>> differently. I think this should be the core/focus of the examples.
>>
>>
>>
>
> The distributed and local/edge nature of COIN nodes may be a specificity
> of those scenarios (in conjunction with other factors like compute/storage
> nature of resources, mobile/battery powered nodes in some cases, etc.) So
> it's possible that centralized mechanisms are less efficient in this
> context, for example. However this view is based on my current
> understanding of COIN in charter and "direction" draft, so it may be off or
> incomplete.
>
> Can you expand? We are thinking of revisiting at least the Milestones and
> that could be a valid input.
>

One use case can be, for mobile devices to decide which AP or data network
to connect to, and to move away from the centralized model used for edge
computing discovery towards a more distributed model for COIN. This is just
one use case, however. I hope that we can discuss with others at IETF 109
about the more general use cases in the discovery overview document.


>
>
>
>>
>>    1. COIN being a RG, I would advise to carefully position the below
>>    examples wrt. state of the art, and outline what/where the proposal is
>>    proposing new (research) things. Again, on the examples, most, if not all
>>    of the pieces/functions could be mapped to existing technologies/protocols.
>>    Can we pinpoint more specifically the technical propositions of COIN in
>>    these contexts?
>>
>>
>   Agreed, these examples were adapted (for most of them) from what is
> present in the existing drafts, they did not go into the technical
> propositions (especially since I was not involved in the data discovery
> drafts). Distributed discovery of a COIN network by mobile nodes could be
> of interest (as opposed to centralized mechanisms for edge computing
> service discovery for example). Also, I think the data discovery overview
> draft points towards multiple specific technical propositions.
>
> I think distributed discovery by any device may be needed as to ne
> recreate bottlenecks that COIN was trying to help :) The question remains:
> how is research going to help the discovery (and I would say orchestration)
> of distributed computing capabilities (and associated storage for example)
> across the core-edge. And feed into the use case drafts.
>
Thanks, it's a good point to look at it from the point of view of the use
case drafts.


> I saw there is a new version of the original discovery draft. How about
> the others?
>
>
> Some aspects of the mobile discovery draft were integrated in the
discovery overview draft. I did not update the mobile discovery draft.
Hopefully this should help keep the discussion more focused.
Best Regards,
Xavier.

> mjm (with a chair hat on and off)
>
>
>
>
>> Please don't take my comments negatively, I'm just trying to get to the
>> core of the issues here; and I think COIN has good potential to deliver
>> compelling research.
>>
>>
>>
>
>   Not at all, thanks again for the comments.
>
>
>> Best regards,
>>
>> Laurent
>>
>>
>>
>> *From:* Coin <coin-bounces@irtf.org> *On Behalf Of *Xavier de Foy
>> *Sent:* Monday, October 26, 2020 20:05
>> *To:* Marie-Jose Montpetit <marie@mjmontpetit.com>
>> *Cc:* coinrg-chairs@irtf.org; coin@irtf.org
>> *Subject:* Re: [Coin] COIN activities update
>>
>>
>>
>> Hi Marie-José, all,
>>
>>   On Wed, Sep 2, 2020 at 9:09 AM Marie-Jose Montpetit <
>> marie@mjmontpetit.com> wrote:
>> > And of course there is the discovery draft has also been going though a
>> number of revisions
>> https://datatracker.ietf.org/doc/draft-mcbride-edge-data-discovery-overview/
>> :
>> > which raised the discussion topic of “in-network” vs. “on-network” and
>> we suppose the reach of computing in the network, a great discussion topic
>> to prepare for our next meetings and milestone updates. There are now 3
>> discovery draft and we welcome a discussion on maybe consolidating them.
>>
>>   Thanks for initiating the discussion. In the hope of contributing to
>> it, here is a set of simplified discovery scenarios (at least as a starting
>> point, please feel free to update it). I think drafts [1][2] cover
>> scenarios (a) and (b), and [3] covers (d). A goal is to frame the discovery
>> scenarios in the context of COIN.
>>
>>   The scenarios involve a "COIN network" (which, based my understanding
>> of the charter, would be made of distributed/decentralized "COIN nodes"
>> providing a computing service integrated with network/transport layers),
>> and endpoints (non-COIN nodes, e.g. COIN network users or external data
>> sources).
>>
>>   a. A COIN node discovers a data source (COIN node or endpoint), for the
>> purpose of influencing COIN network operation (e.g. code placement, request
>> routing, input for computation). Data discovery information may be further
>> disseminated between COIN nodes. In a related scenario a COIN node
>> discovers an external network function (e.g. SFC node), for the purpose of
>> using the service, influencing request routing, and placing the code that
>> uses the service.
>>
>>   b. A COIN node discovers computing/storage resources, for the purpose
>> of creating/instantiating new COIN nodes.
>>
>>   c. A COIN node discovers another COIN node (that belongs to a different
>> domain), for the purpose of interfacing 2 different COIN networks.
>>
>>   d. An endpoint or COIN node (which can be multihomed) discovers a COIN
>> network entry point, for the purpose of connecting to it (e.g., as a user,
>> or to join a COIN network). As a variant for wireless devices, mobile
>> endpoints may need to determine which AP to attach to, in order to access a
>> COIN network entry point.
>>
>>   To come back to the consolidation discussion, would the RG community be
>> willing to work on a document covering all or some scenarios listed here?
>>
>>   Best Regards,
>>
>> Xavier.
>>
>> [1] draft-mcbride-edge-data-discovery-overview
>> [2] draft-mcbride-data-discovery-problem-statement
>> [3] draft-defoy-coinrg-mobile-discovery
>>
>