Subject: Re: [Coin] Fwd: New Version Notification for draft-kutscher-coinrg-dir-00.txt

From: <[email-masked]>
Date: Mon, 4 Nov 2019 17:44:01 +0000

Dirk, Teemu, Jörg,

I've now got to reading your draft. Thanks - I agree with most of it and think it's useful.

Somewhere in Section 3 - perhaps you could explain the differences from MEC & slicing (I think I know what they are, but may be a question some readers ask themselves)

In S3 / 3.3, I thought it could be clearer where you stop talking about existing systems (which << might intuitively be characterized as "computing in the network">>) and start talking about COIN.

S3.4 - I agree, as you hint, that we should be interested in moving beyond lambda functions to sets of (micro-) functions that are chained /meshed, functions that instantiate other functions etc

<< The underlying architectural question is whether the goal is to enable the network to perform computations on the data passing through it, or whether the goal is to enable distributed computational processes to be built in the network.>>
Am I allowed to say I want both?!

Re heterogenous platforms. I hope COIN will allow different platforms (physical & virtualisation technologies) to be integrated in the COIN. 

S4 - I agree that the joint resource optimisation problem (across compute & networking resources) is an interesting research problem and (I believe) could give great gains.

S4.2 - strictly stateless vs stateful. I don’t think we should assume only strictly stateless functions. 
<< keep state over a series of function invocations>> I think we will have a series of micro-functions, which I think implies some state. I'm undecided about whether we should aim to keep state over a series of invocations of the same function (but probably, Yes)

S4.5 another security aspect of this could be how to be sure the function does what it claims it will do.

S4.6 - I like the idea of re-starting a function as a way of handling failure (or at least as a possible method). Need to avoid significant virtualisation (& networking) overheads from enforcing extreme quality of service when many users may not need it. 

It might be good to illustrate some of the points further through an example? - perhaps based round the one in your ICN-19 paper (analysis of coughing to see which passengers are ill)

Thanks!
Best wishes,
phil

-----Original Message-----
From: Coin <[email-masked]> On Behalf Of Dirk Kutscher
Sent: 08 July 2019 20:47
To: [email-masked]
Subject: [Coin] Fwd: New Version Notification for draft-kutscher-coinrg-dir-00.txt

Hello,

We have written up some ideas on COIN Research Directions -- hope you find that useful.

Naturally, we’d be interested in feedback — either on the list or at the meeting in Montreal.

Best regards,

Dirk, Teemu, Jörg

Forwarded message:

> From: [email-masked]
> To: Joerg Ott <[email-masked]>, Teemu Karkkainen <[email-masked]>, 
> Teemu Kaerkkaeinen <[email-masked]>, Dirk Kutscher 
> <[email-masked]>
> Subject: New Version Notification for draft-kutscher-coinrg-dir-00.txt
> Date: Mon, 08 Jul 2019 12:41:52 -0700
>
> A new version of I-D, draft-kutscher-coinrg-dir-00.txt has been 
> successfully submitted by Dirk Kutscher and posted to the IETF 
> repository.
>
> Name:		draft-kutscher-coinrg-dir
> Revision:	00
> Title:		Directions for Computing in the Network
> Document date:	2019-07-08
> Group:		Individual Submission
> Pages:		17
> URL:            
> https://www.ietf.org/internet-drafts/draft-kutscher-coinrg-dir-00.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-kutscher-coinrg-dir/
> Htmlized:       
> https://tools.ietf.org/html/draft-kutscher-coinrg-dir-00
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-kutscher-coinrg-dir
>
>
> Abstract:
>    In-network computing can be conceived in many different ways - from
>    active networking, data plane programmability, running virtualized
>    functions, service chaining, to distributed computing.
>
>    This memo proposes a particular direction for Computing in the
>    Networking (COIN) research and lists suggested research challenges.
>
>
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> The IETF Secretariat

--
Coin mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/coin

---

From: "Dirk Kutscher" <[email-masked]>
Date: Mon, 04 Nov 2019 21:57:27 +0100

Thanks, Phil,

That was just in time.

We have just submitted an update that reflects some of your points (see 
other message).

Of course, there is more to be discussed — let’s do that on the list 
and in Singapore.

Thanks,
Dirk

On 4 Nov 2019, at 18:44, [email-masked] wrote:

> Somewhere in Section 3 - perhaps you could explain the differences 
> from MEC & slicing (I think I know what they are, but may be a 
> question some readers ask themselves)
>
> In S3 / 3.3, I thought it could be clearer where you stop talking 
> about existing systems (which << might intuitively be characterized as 
> "computing in the network">>) and start talking about COIN.
>
> S3.4 - I agree, as you hint, that we should be interested in moving 
> beyond lambda functions to sets of (micro-) functions that are chained 
> /meshed, functions that instantiate other functions etc
>
> << The underlying architectural question is whether the goal is to 
> enable the network to perform computations on the data passing through 
> it, or whether the goal is to enable distributed computational 
> processes to be built in the network.>>
> Re heterogenous platforms. I hope COIN will allow different platforms 
> (physical & virtualisation technologies) to be integrated in the COIN.
>
> S4 - I agree that the joint resource optimisation problem (across 
> compute & networking resources) is an interesting research problem and 
> (I believe) could give great gains.
>
> S4.2 - strictly stateless vs stateful. I don’t think we should 
> assume only strictly stateless functions.
> << keep state over a series of function invocations>> I think we will 
> have a series of micro-functions, which I think implies some state. 
> I'm undecided about whether we should aim to keep state over a series 
> of invocations of the same function (but probably, Yes)
>
> S4.6 - I like the idea of re-starting a function as a way of handling 
> failure (or at least as a possible method). Need to avoid significant 
> virtualisation (& networking) overheads from enforcing extreme quality 
> of service when many users may not need it.
>
> It might be good to illustrate some of the points further through an 
> example? - perhaps based round the one in your ICN-19 paper (analysis 
> of coughing to see which passengers are ill)
>
> Thanks!
> Best wishes,
> phil
>