Re: [core] Using CoAP for P2P

Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com> Fri, 03 April 2020 15:46 UTC

Return-Path: <abhijan.bhattacharyya@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB903A1952 for <core@ietfa.amsl.com>; Fri, 3 Apr 2020 08:46:42 -0700 (PDT)
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 n4VAfph6cSwf for <core@ietfa.amsl.com>; Fri, 3 Apr 2020 08:46:40 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 0983B3A1943 for <core@ietf.org>; Fri, 3 Apr 2020 08:46:39 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id e5so9792794edq.5 for <core@ietf.org>; Fri, 03 Apr 2020 08:46:39 -0700 (PDT)
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=N2iWSsVa4ye2RF1kh+ucTx1PT0Dcm9yb8AjtPvfBmgs=; b=sjmY7rM/nyITxazvECOy0XjDTS+YIQWiFmjjd2gVq41IceOgEhFUF+HFj0RSorSvXs iTez+U9Ot1VA5/wvGml0S6X1/orrJpr2lmXIkIf+OtE9xmuNxJU+hJjUeAGB5qjNqGDL Jf2afppauiMK/rrPP1WP3387Uq9An/bshZ3wl0kM7H3T2D2ZjnWPZNWkzXeD1PwMLXLx XJm/lnZAkC3fonjC8Qy63o4jKyt5tRK0usFw+LAj3fZC+ctGMJEb2ygZ1z7V9S9Oj71l mAkxZ4lymjBEI/bv06luiMNu4ppqaitk21lo3qWIhp0MjVOt6udHe6/fbcynQS5DXZZW /ksg==
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=N2iWSsVa4ye2RF1kh+ucTx1PT0Dcm9yb8AjtPvfBmgs=; b=GBJGXSo2oBKZ+8xUlsj4CH6zi+j3lOKkbFCwDUTqIqs4Zvo+l7SaEdhxEiU6yg+ab5 j9adtRalfL4Z3nNmbpSWdsqOmmYdP4I8g2azzY0pdtTMJvk5vZR1sbFtm2raCPccWvK6 uXhgo5N3Ejv5DlC1YdnVIJdr8fjVchLxOluIxfNS2GpUHT9Uyehhwr9kBySojryBjLDx 5iUX1wo9Cg0AINDZ7FNU/NTr3NLhvlz0dWA/UtCCSzro1MygVFNmJlRMgNCM33p+c/pn z/Ce+x4F5D5aml4WRL3wjoI9r9ZMDrQB5/edGoEmVgI4EAAskfAds/jLZK+n9okE2iEJ Ek6w==
X-Gm-Message-State: AGi0PubQvMOn2qq/Gg6QlJnt8J8D2gmmcKS4Foa5LRHHYUnKyPgbINu2 PjQ6BsMHMRI/aJ+EYGuImiHmbCdIRo7R+1oMqRM=
X-Google-Smtp-Source: APiQypIeElTqj8GYwzezp68Df85Wvv6XnzNBMbXlX1Qbb+ptoYqKEjSV/suxFTe+u4uFXL6p2nvbtUn7AbIducjQsNA=
X-Received: by 2002:a50:cc87:: with SMTP id q7mr8151581edi.96.1585928798349; Fri, 03 Apr 2020 08:46:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAEW_hyzh3FAvHi1eTkbyGn99o4nFgcH1xP90FdQ6N9sHsAJVYQ@mail.gmail.com> <A8E6E9AA-2E34-439E-8761-53385086CDB9@arm.com> <CAEW_hyy+0fViN8dMWiCi_QHjeD5J4DUAnoRUg5MAKS6fQ3DzcQ@mail.gmail.com> <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com>
In-Reply-To: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com>
From: Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com>
Date: Fri, 3 Apr 2020 21:16:22 +0530
Message-ID: <CAEW_hyzbtq6VbQMq5PhfAQjf6LLz-7t_9He-C_kaU5jztsf20A@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Thomas Fossati <Thomas.Fossati@arm.com>, core <core@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aa2e7605a264d2a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/UdhGD7laUdXcBHd2yBWd78kFrPo>
Subject: Re: [core] Using CoAP for P2P
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2020 15:46:43 -0000

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 <
christer.holmberg@ericsson.com> 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:
>
>
>
>
> https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-thin-ICE-151119-Singapore.pdf
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From: *core <core-bounces@ietf.org> on behalf of Abhijan Bhattacharyya <
> abhijan.bhattacharyya@gmail.com>
> *Date: *Thursday, 2 April 2020 at 11.04
> *To: *Thomas Fossati <Thomas.Fossati@arm.com>
> *Cc: *core <core@ietf.org>
> *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.
>
>
>
> Is there any standardized mechanism to handle this situation?
>
>
>
> Thanks.
>
>
>
> On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati <Thomas.Fossati@arm.com>
> wrote:
>
> Hi Abhijan,
>
> On 01/04/2020, 12:31, Abhijan Bhattacharyya <
> abhijan.bhattacharyya@gmail.com> wrote:
> > 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.
>
>
>
>
> --
>
> Regards,
>
> Abhijan Bhattacharyya,
>
> *Technologist by profession [IoT| Internet Protocols| 5G]*
>


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