Subject: [Coin] Discussing the charter

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 16 Nov 2018 13:00:17 -0500

The most important thing to do for COIN before the next IRTF is discussing the charter.  It is on the wiki: https://trac.ietf.org/trac/irtf/wiki/coin

The current text tries to be generic, most likely too much so, and the discussions at last week's meeting clearly showed that we need to define the type of research that is in COIN and what is not. Because of the current implementations a lot of the “computing in the network” happens in datacenters. But those are a very specific subnetwork type and even there security and transport still need to be addressed. At the meeting we had presentation on some edge issues. And then of course there is the links between the DCs and the edge: those are also potential candidates for in-network programmability. The big question will be if we can find commonalities between these segments that can drive COIN as a single entity not 3 separate segments. And of course, like any other RG some of the work is most likely more ready for primetime than others.

Your inputs are incredibly valuable.

Here in the US we are getting the Thanksgiving break so maybe not the best time to start heavy technical discussions :)

But it’s great to be able to reach the community :)

Happy weekend.

Marie-José and Jeffrey

Marie-Jose Montpetit, Ph.D.
[email-masked]
[email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 17 Nov 2018 12:04:16 +0000

That looks good to me - do we want to spell out some specific COIN
technical strands of work and possible outcomes

for example, orchestration is a hard enough problem at scale, but with
heterogeneous components, it gets tricker - generally, DC
swarm/kubernetes stuff isn't going to work in the multi-admin-domain
space either

plus programming heterogeneous systems is becoming mainstream again
(mainly due to the plethora of i) offloading support (tcp, crypto,
compression and accelerator support for ML (GPU, FPGA, TPU etc)... but
the mixes are of processors that are extremely tightly coupled (to the
extend of even having core affinity stuff between "main" system and
supporting system/offload/accelerator) - same model happens in mobile
space in handsets....but when you separate the two types of system by
a higher latency (lower relaibility) link, things change...how? this
is where the end of end-to-end rubber hits the road...

so also we are now entering the space of multi-party computations -
this makes crypto/security properties a lot different - there were
some tentative steps in this area (where telefonica folks were pushing
up opening https/tls to having middle boxes party to the crypto
stream, presumably to push ads in from the center, rather than just
sitting watching google make all the ad money from the end
system....there are probably better motives for doing this, and doing
it with a more general architecture that offers the right
privacy/confidentiality/integrity properties...

i'm sure there's more to add in the list of possible things to tackle

as well as jen rexford's sigcomm keynote, i think this paper is a
great one-stop-shop for a lot of the history behind this space:

The Road to SDN: An Intellectual History of Programmable Networks, from here:

https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistory.pdf

cheers
jon
On Fri, Nov 16, 2018 at 6:00 PM Marie-Jose Montpetit
<[email-masked]> wrote:
> --
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 17 Nov 2018 08:13:07 -0500

See below.
+1-781-526-2661
@SocialTVMIT

> On Nov 17, 2018, at 7:04 AM, Jon Crowcroft <[email-masked]> wrote:
> 
Agree. I think maybe we want to clearly state what is now implemented and what is the goal of current and new research.
> is where the end of end-to-end rubber hits the road…
You raise an excellent point. When all devices are colocated things are easier (in fact you can get away from “standard” protocol completely. But when they are separated then issues of protocol inefficiency become potential not only bottlenecks but also no-gos (transport and security are some) 
> privacy/confidentiality/integrity properties…
Agreed. This is why I would like COIN to encompass those middleboxes that may be part of the end to end performance improvements not as ad servers but for enhanced congestion control, erasure coding etc.

> i'm sure there's more to add in the list of possible things to tackle

This is what I want this discussion to address. And then there will be 2 outcomes:
1. an improved charter
2. an “achitecture” overview draft with “architecture” not solely in terms of location but common protocols, abstraction and functional decomposition. And with use cases to stress that architecture (applications and services).
> https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistory.pdf <https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistory.pdf>

I have Jennifer’s keynote in the wiki’s references.

Thanks!!!!

mjm