Subject: [core] Using CoAP for P2P

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 1 Apr 2020 17:00:46 +0530

Hi,
Is there any standardized mechanism to use CoAP for a P2P connection?
Thanks.

-- 
Regards,
Abhijan Bhattacharyya,
*Technologist by profession [IoT| Internet Protocols| 5G]*

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 1 Apr 2020 12:02:10 +0000

Hi Abhijan,

> Is there any standardized mechanism to use CoAP for a P2P connection?

Not sure whether RFC 7650 would fit your needs but worth having a
look -- if you haven't already.

cheers
--

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 2 Apr 2020 13:33:47 +0530

Hi Thomas,
What I am looking at is a situation where I have two nodes each having a
time-varying resource. Both want to push the states of the respective
resource to the other node within a common application context. However,
these exchanges are naturally asynchronous. May be I can think of it more
like a chat. A typical client-server or observe relationship will not serve
the purpose. Actually both should have a client and server instance running
under a common application. Then either each can *observe* the other, or
can *post* the other. That is how we can do that without a central server.

If my understanding is right, according to CoAP specification, the nodes
which can have both server and client (to the origin server) are
"intermediary" nodes. The only example of "intermediary" considered in the
spec is the proxy node. But, anyway the situation in this case does not
concern with intermediary. Both are origin server and end-client together.

Is there any standardized mechanism to handle this situation?

Thanks.

On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati <[email-masked]>
wrote:

> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 2 Apr 2020 10:45:27 +0000

Hi Abhijan,

On 02/04/2020, 09:04, "Abhijan Bhattacharyya"
<[email-masked]> wrote:
> What I am looking at is a situation where I have two nodes each having
> a time-varying resource. Both want to push the states of the
> respective resource to the other node within a common application
> context. However, these exchanges are naturally asynchronous.  May be
> I can think of it more like a chat. A typical client-server or observe
> relationship will not serve the purpose. Actually both should have a
> client and server instance running under a common application. Then
> either each can *observe* the other, or can *post* the other. That is
> how we can do that without a central server.

What you describe above is a perfectly reasonable implementation: each
node has both client and server endpoints where the former observe the
latter on the peer.  To share state across co-located endpoints one can
use an IPC of choice including shared memory between threads.

> If my understanding is right, according to CoAP specification, the
> nodes which can have both server and client (to the origin server) are
> "intermediary" nodes. The only example of "intermediary" considered in
> the spec is the proxy node. But, anyway the situation in this case
> does not concern with intermediary. Both are origin server and
> end-client together.

7252 says that an intermediary has both client and server endpoints, not
that any node with both client and server endpoints is an intermediary.

> Is there any standardized mechanism to handle this situation?

The design you've described above is a standardised (and logical) way to
handle your case.

cheers, t
--

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Apr 2020 18:41:32 +0000

Hi,

If you are interested in P2P, you might be interested in the thin-ICE presentation that was given at the T2TRG meeting in Singapore:

https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-thin-ICE-151119-Singapore.pdf

Regards,

Christer

From: core <[email-masked]> on behalf of Abhijan Bhattacharyya <[email-masked]>
Date: Thursday, 2 April 2020 at 11.04
To: Thomas Fossati <[email-masked]>
Cc: core <[email-masked]>
Subject: Re: [core] Using CoAP for P2P

Hi Thomas,
What I am looking at is a situation where I have two nodes each having a time-varying resource. Both want to push the states of the respective resource to the other node within a common application context. However, these exchanges are naturally asynchronous. May be I can think of it more like a chat. A typical client-server or observe relationship will not serve the purpose. Actually both should have a client and server instance running under a common application. Then either each can *observe* the other, or can *post* the other. That is how we can do that without a central server.

If my understanding is right, according to CoAP specification, the nodes which can have both server and client (to the origin server) are "intermediary" nodes. The only example of "intermediary" considered in the spec is the proxy node. But, anyway the situation in this case does not concern with intermediary. Both are origin server and end-client together.

Thanks.

On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:
Hi Abhijan,

cheers
--

--
Regards,
Abhijan Bhattacharyya,
Technologist by profession [IoT| Internet Protocols| 5G]

---

From: Mehmet Adalier <[email-masked]>
Date: Thu, 02 Apr 2020 12:23:49 -0700

As far as I know, a CoAP node can be provisioned to provide both client and server functionality and change the behavior as required (i.e. act as a client when it is doing client work and act as a server/resource when doing server work). Our implementation runs a daemon that can instantiate multiple clients/servers on a single computing node.

If you do not want to set up a Broker/Intermediary as a separate node (e.g., pubsub), then you can make one of your nodes also a “a broker”

and create your topics on that one (e.g., chatboard topic). Then each node can subscribe to the topic as well as publish to the topic. 

The described approach will support P2P and reduce traffic.

mehmet

From: core <[email-masked]> on behalf of Christer Holmberg <christer.holmberg=[email-masked]>
Date: Thursday, April 2, 2020 at 11:41 AM
To: Abhijan Bhattacharyya <[email-masked]>, Thomas Fossati <[email-masked]>
Cc: core <[email-masked]>
Subject: Re: [core] Using CoAP for P2P

Hi,

Regards,

Christer

Hi Thomas, 

Thanks.

On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati <[email-masked]> wrote:

Hi Abhijan,

cheers
--

 

-- 

Regards,

Abhijan Bhattacharyya,

_______________________________________________ core mailing list [email-masked] https://www.ietf.org/mailman/listinfo/core

---

From: Mehmet Adalier <[email-masked]>
Date: Thu, 02 Apr 2020 12:23:49 -0700

mehmet

Hi,

Regards,

Christer

Hi Thomas, 

Thanks.

Hi Abhijan,

cheers
--

 

-- 

Regards,

Abhijan Bhattacharyya,

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 3 Apr 2020 21:16:22 +0530

HI Thomas,
Thank you for your response. It helps understand the spec better.

Hi Christer,
Thanks for sharing the slides.
So, if both the nodes host a resource which the other one is interested in,
then, following the diagram in the slides, Device #2 should also post and
create a resource and Device #1 should do a GET. Then both the devices can
access each other, right? Can we then think of a situation when the RD and
the TURN server merges together?

One thing that I find special in this case than usual P2P establishment
scenario is that, the TURN server has the responsibility of notifying the
URI as well and not only the ip:port mapping. This is because of the
RESTful semantics.

Can we find any document elaborating these slides?
And, is there any opensource implementation available of this proposal
please?

A bit of more inputs:
We proposed a delay-sensitive time-series streaming mechanism by extending
CoAP and presented in last Bangkok IETF. We called it A-REaLiST (Adaptive
RESTful Real-time Live Streaming for Things).
The draft is here:
https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-00
The relevant research work was published in 2018 Globecom workshop: Abhijan
Bhattacharyya, Suvrat Agrawal, Hemant Kumar Rath, Arpan Pal: "Improving
Live-Streaming Experience for Delay-Sensitive IoT Applications: A RESTful
Approach" (https://ieeexplore.ieee.org/document/8644521).

We then further extended this solution for a two way communication for
tele-medicine use case under constrained environment and published in 2019
EuCNC: Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Kumar Rath, Arpan Pal:
"Towards Democratizing E-health Under Constrained ICT Infrastructure
Through ‘A- REaLiST’ Solution" (
https://ieeexplore.ieee.org/abstract/document/8802034/)

A standardized mechanism to establish P2P connection would be beneficial in
such a case.

Regards,
Abhijan

On Fri, Apr 3, 2020 at 12:11 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> If you are interested in P2P, you might be interested in the thin-ICE
> presentation that was given at the T2TRG meeting in Singapore:
>
>
>
>
> *From: *core <[email-masked]> on behalf of Abhijan Bhattacharyya <
> [email-masked]>
> *Date: *Thursday, 2 April 2020 at 11.04
> *To: *Thomas Fossati <[email-masked]>
> *Cc: *core <[email-masked]>
> *Subject: *Re: [core] Using CoAP for P2P
>
>
>
> Hi Thomas,
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 4 Apr 2020 12:26:03 +0000

Hi,

>A bit of more inputs:
>We proposed a delay-sensitive time-series streaming mechanism by extending CoAP and presented in last Bangkok IETF. We called it A-REaLiST (Adaptive RESTful Real-time Live Streaming for Things).
>The draft is here: https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-00
>The relevant research work was published in 2018 Globecom workshop: Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Kumar Rath, Arpan Pal: "Improving Live-Streaming Experience for Delay-Sensitive IoT >Applications: A RESTful Approach" (https://ieeexplore.ieee.org/document/8644521).

What exactly do you want to standardize? As long as one device acts as a client, and the other as a server, the current mechanisms should work.

Now, if you want to send GETs etc in both directions, I assume that each endpoints would act as both client and server.

Regards,

Christer

On Fri, Apr 3, 2020 at 12:11 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-thin-ICE-151119-Singapore.pdf<https://protect2.fireeye.com/v1/url?k=7a432dea-26972098-7a436d71-86859b2931b3-a91f2d2ed99da951&q=1&e=b329b088-d6d0-4446-8ddf-5589a9e3abcd&u=https%3A%2F%2Fgithub.com%2Ft2trg%2F2019-11-singapore%2Fblob%2Fmaster%2Fslides%2F44-thin-ICE-151119-Singapore.pdf>

Regards,

Christer

From: core <[email-masked]<mailto:[email-masked]>> on behalf of Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 2 April 2020 at 11.04
To: Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Cc: core <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] Using CoAP for P2P

Hi Thomas,

Thanks.

cheers
--

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Sun, 5 Apr 2020 17:46:46 +0530

Hi Christer,
Probably what can  be standardized is a method for signalling and
exchanging the ICE candidates so that end nodes can mutually push the data
to the other. Signalling may include resource discovery.

Your proposal looks useful for the purpose. Extending the example towards
two sided exchange might help.

We shall be interested to try it out if there is any open-source
implementation.

Thanks.

On Sat, 4 Apr 2020, 17:56 Christer Holmberg, <[email-masked]>
wrote:

> Hi,
>
>
>
> >A bit of more inputs:
>
> >We proposed a delay-sensitive time-series streaming mechanism by
> extending CoAP and presented in last Bangkok IETF. We called it A-REaLiST
> (Adaptive RESTful Real-time Live Streaming for Things).
>
> >The draft is here:
> >The relevant research work was published in 2018 Globecom
> workshop: Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Kumar Rath, Arpan
> Pal: "Improving Live-Streaming Experience for Delay-Sensitive IoT
> >Applications: A RESTful Approach" (
> https://ieeexplore.ieee.org/document/8644521).
>
>
>
> What exactly do you want to standardize? As long as one device acts as a
> client, and the other as a server, the current mechanisms should work.
>
>
>
> Now, if you want to send GETs etc in both directions, I assume that each
> endpoints would act as both client and server.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
> <https://protect2.fireeye.com/v1/url?k=7a432dea-26972098-7a436d71-86859b2931b3-a91f2d2ed99da951&q=1&e=b329b088-d6d0-4446-8ddf-5589a9e3abcd&u=https%3A%2F%2Fgithub.com%2Ft2trg%2F2019-11-singapore%2Fblob%2Fmaster%2Fslides%2F44-thin-ICE-151119-Singapore.pdf>
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 11:25:55 +0000

Hi,

> Probably what can  be standardized is a method for signalling and exchanging the ICE candidates so that end nodes can
> mutually push the data to the other. Signalling may include resource discovery.

Yes, one could split things up into separate pieces as far as standardization is concerned.

One piece is to simply collect candidates using CoAP. Another piece is the candidate exchange.

> Your proposal looks useful for the purpose. Extending the example towards two sided exchange might help.

Sure. If this would be standardized, that should at least be considered.

> We shall be interested to try it out if there is any open-source implementation.

Me too :)

Regards,

Christer

On Sat, 4 Apr 2020, 17:56 Christer Holmberg, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,

Christer

Hi Thomas,

Thanks.

cheers
--

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 6 Apr 2020 13:47:07 +0200

Hi Abhijan,

> On 2020-04-05, at 14:16, Abhijan Bhattacharyya <[email-masked]> wrote:
> 
> Probably what can  be standardized is a method for signalling and exchanging the ICE candidates so that end nodes can mutually push the data to the other. 

Have we already established that you do need ICE?
I agree that in a NATted, IPv4 environment ICE is a good way to obtain useful address pairs.
Can you run your application in a clean IPv6 environment?
Then you don’t need ICE; everything just falls into place.

Grüße, Carsten

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 11:52:21 +0000

Hi,

    >Then you don’t need ICE; everything just falls into place.

I am not going to get involved in a discussion about that, because it is not CORE specific, but IPv6 is *NOT* going to remove the need for NATs :)

Regards,

Christer

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 6 Apr 2020 14:13:06 +0200

> I am not going to get involved in a discussion about that, because it is not CORE specific, but IPv6 is *NOT* going to remove the need for NATs :)

Of course not, IPv6 is not removing IPv4… :-)

(That’s why I talked about a “clean” environment.)

Grüße, Carsten

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Mon, 6 Apr 2020 18:01:42 +0530

Hi Carsten,
Considering the practical deployment possibilities, I think we are quite
far from expecting a clean IPv6 path. My home broadband service provider
still serves IPv4 only. :)
Apart from that there may always be some firewall in place considering
enterprise use cases and we would need to punch a hole.
Thanks.

On Mon, Apr 6, 2020 at 5:43 PM Carsten Bormann <[email-masked]> wrote:

> > I am not going to get involved in a discussion about that, because it is
> not CORE specific, but IPv6 is *NOT* going to remove the need for NATs :)
>

---

From: Achim Kraus <[email-masked]>
Date: Mon, 6 Apr 2020 15:23:59 +0200

Hi Abhijan,

in my experience it's not about IPv4 or IPv6 (and the feature assumed to
be included with both technologies).

It's about the nature of the network you use for your peers to
communicate. CoAP over UDP (also over DTLS/UDP) works without the need
of additional parts, if your peers can exchange messages using UDP.

So, is that network your peers are using fully under your control? As a
home-network maybe considered. So, you know, if your peers have static
or mainly static addresses. And there is nothing on the path between
your peers, which may block or modify your traffic? Then you have a very
good chance, that you don't need something additionally.

But, if your peers can't reach each other without additional parts, e.g.
because both in "their home network" and so communicate over a path,
which uses a "public internet link", then you need more.

Therefore, please try to describe first the network(s) and the
communication paths you plan to use for your peers.

best regards
Achim

Am 06.04.20 um 14:31 schrieb Abhijan Bhattacharyya:
> On Mon, Apr 6, 2020 at 5:43 PM Carsten Bormann <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     On 2020-04-06, at 13:52, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      > I am not going to get involved in a discussion about that,
>     because it is not CORE specific, but IPv6 is *NOT* going to remove
>     the need for NATs :)
>
> /Technologist by profession [IoT| Internet Protocols| 5G]/
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 7 Apr 2020 01:31:49 +0530

Hi Achim,
I think we can put it this way:
When we consider a purely Client/Server mode, there is this inherent
assumption that usually the server will have the implicit responsibility to
make itself available through a known accessible path. This does not hold
as a general consideration when we want to do a P2P that should not depend
only on a given assumption about the path to reach the peers.

The peers may both be publicly addressable; one or both may be behind NAT/
Firewall; they may be in a home network where filtering rules are relaxed;
they may be in an enterprise network with stricter rules (at times you may
need the local infra admin to intervene to open specific ports -- let's
keep that out of consideration here). So, any possible standardization
effort should propose a mechanism that will allow the peers to access each
other agnostic of the intermediate topology and the back haul.

Thanks.

---

From: John Carter <[email-masked]>
Date: Tue, 7 Apr 2020 08:48:18 +1200

While the standard is, unlike the http standard, agnostic as to who is the
client and who is the server and the roles can switch.... in practical
experience I'd advise caution.

1. If you are not careful you end up with a system that only works if and
only if all nodes are up and working. The best thing about REST is it
reduces coupling and dependencies between client and server. If you two way
couple them, you have made the coupling a lot stronger.

2. If you are not careful, you can end up with update loops. ie. Node A
updates an observable resource, in response to which Node B updates a
derived observable resource, which Node.... updates a derived observable
resource, which triggers an update on Node A and around we go.

-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

-- 
This Communication is Confidential. We only send and receive email on the

basis of the terms set out at www.taitradio.com/email_disclaimer 
<http://www.taitradio.com/email_disclaimer>

---

From: John Carter <[email-masked]>
Date: Tue, 7 Apr 2020 08:48:18 +1200

-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 7 Apr 2020 18:46:58 +0530

Yes, these are typical implementation considerations.
Particularly if we consider the case in point number 2, any control system
design must keep the stability of the system in mind. However, there will
be many cases where the exchanges are not necessarily synchronous. A
strictly synchronous model could probably be implemented with a typical
client server relationship using POST request and response payload
intelligently. P2P should be agnostic of any possible relationship between
the resources.

Thanks.

On Tue, Apr 7, 2020 at 2:18 AM John Carter <[email-masked]>
wrote:

> ------------------------------
> ------------------------------
>