Re: [core] Using CoAP for P2P: thin-ICE

Christer Holmberg <> Sat, 04 April 2020 12:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD1883A0B5D for <>; Sat, 4 Apr 2020 05:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jtkKJLlaLa7Z for <>; Sat, 4 Apr 2020 05:23:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81D603A0B41 for <>; Sat, 4 Apr 2020 05:23:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=bnXJ6c6etLiuzQ04lsxQ6uYyR3/ayImCQ9nzUwOSdkoXiQ3H49ACMx2p79Uy8+QYmP9Q65pOJJ4fGc1gyW6Wycocdg0Hx2Q5KCwaAjh1gbbZIrDj4vveRzsvyrEhGOH8Rs+8cPvdOGJasQFe0w8pkByRVd8/ishBjdc9r2lo82PfYcJTAj1mVqVBnO0r6HWeAF49qeDRFpKzPNMqskquW17fS9Q9aSA2kbJzsaw3cDcBsV4e8fOqUcBnBjg3Yb70GPt0kMvFwnYtxE7WGEfYCrNwf10mGKowIlt6T/WjYMRf4iqeKY/qBOX7S/q0RDPkKcmTjAyWO4tp1tP+lytbMw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wnxKx4b2WrPnSlR3eTop9ua7nfgLitlPyEAS3GmJHyY=; b=V8iJO9S4BccSs4ft+BBozi0J2C9Zfy5MQao+TzMVDOEJiqWfWDhdxaQbEnQ3FAtGUvzH1ljg4n+4v+6hpAAfpA3dDCI9loml4+DtPfNXbb22TNAsKTWjd6bzqdUq2BC/0op5kQiCrJv1w9lDAxXdrEqHynqwK0+n/3NNL8pqwI3qpXCAccN4aoGn74dxOCwJyrZrBtnTcvot4UVQCc0iPoPBYpNbDF7+lon92/s2La4VS0fn5oVpz6BiBhMorKB9aq7w3kMi60DMALp1ZWGVK/wC4grfwRK7YQtQAIHhZFkAhEnBMfDKq5In5gsJ5uitZ+5n2cbPZCGWX9RDe/SXnw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wnxKx4b2WrPnSlR3eTop9ua7nfgLitlPyEAS3GmJHyY=; b=N9a3wuk1A0L/Q4o8ZTK2wWyccgxq1s+Xn5DHANkv2mi1+p5dYEheWXWmzE5fr6I3UHopSPIP/ae80lZLZkVFYfJO3srd42bY/SJiKsUUnnCAVeSj7/ZgvO3LKetSAFZxQd6onxFbJyZ3iwBlCCHZpWYslRW3wqZs/wNWOGRHKYk=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.11; Sat, 4 Apr 2020 12:23:11 +0000
Received: from ([fe80::57b:b81e:33ec:5512]) by ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2900.012; Sat, 4 Apr 2020 12:23:11 +0000
From: Christer Holmberg <>
To: Abhijan Bhattacharyya <>
CC: Thomas Fossati <>, core <>
Thread-Topic: [core] Using CoAP for P2P: thin-ICE
Thread-Index: AQHWCnvOvRwVXrVfdU6sUF31AU5OKA==
Date: Sat, 04 Apr 2020 12:23:11 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3e27ee12-116f-499c-5ef9-08d7d892f105
x-ms-traffictypediagnostic: AM0PR07MB5139:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03630A6A4A
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(396003)(136003)(346002)(8676002)(66556008)(26005)(66446008)(66574012)(76116006)(91956017)(54906003)(5660300002)(186003)(66476007)(316002)(6506007)(71200400001)(66946007)(6916009)(53546011)(44832011)(966005)(64756008)(86362001)(478600001)(6512007)(33656002)(36756003)(6486002)(8936002)(81166006)(2906002)(81156014)(4326008)(2616005); DIR:OUT; SFP:1101;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XMbZB/WsGlQ2Q/av8p9clVszYnn7PNCq5pAZujKENlNeUZe7ST5XAxJKTqy6jOpP+W+QcTfPgHydLp+YhrmJTsOJLLftl+F/0INw5afZjkuDUS6h+PaI80fBjxPKrINl01cUQNL7hzHxDXgb67M9gyfyfNCUkBB1CwzoawhKceVPiqXZSZKkM8cgbs8h6x5UWJxO9RoHTPcxWDwL0Oa0oTRbZ+eCahPMO8Nwn0ck1d89VU5Y4Ja02JnIbQoXD6bLXpe8toewNo0toavhNri1/m+9oS54mcFZy+Cf+P0wYpZ5yzfQC/Fz03M3hSgOKDFqVgT/S0bd5SjxgSVs7ntIbihyKzKGXa5wZgtllyCTqiuH0Mi3YP9FtanV6OCNX3TtBx/oO6T95JGzI8TKW278/591rGMiSSQGmrRuZiZTSjOgS6O0aiX/9ipQqF01jhAXUgf2YZMvI8xKdVJrLE/AdXLYXG4CKvQ7fzZekSlPNfQ+puOHz9y184VwJw9YOgFXZvsSEGB1LHHfvvxfrRHSVQ==
x-ms-exchange-antispam-messagedata: a/R78HLCm7dJsHcjju0PwFa62Q+wQalNNpx9jeI3wkNchlr+h/ac/BHzDxMovaiXUubYxl3n9a0YFIL3kIwf5kXwRNoJ7F6NyEdsJ6HXAwXVB4iE/BxF2uozCIs1lGXYaVj0EOr4vhJaRiZoNGFnJg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_D920651491F44DDB8ED0C609F3DD6582ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e27ee12-116f-499c-5ef9-08d7d892f105
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2020 12:23:11.5311 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +iuhegPVyWmwRBdSB3ChvqEmlXQ3VIfNQeD4d4TqURAGTLlo9zHE3T9guRb/WIz6bcp0acYOOG8fM0iT1BvQLmm8LOI5FpfdqJj//deroTA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5139
Archived-At: <>
Subject: Re: [core] Using CoAP for P2P: thin-ICE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Apr 2020 12:23:17 -0000


> 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?


(Of course, when Device #1 has received the GET from Device #2, Device #1 could try to reach Device #2 using the address from where the GET was received. That is referred to as a peer reflexive candidate in ICE, but we have not looked into that in detail yet.)

> Can we then think of a situation when the RD and the TURN server merges together?

Not sure what you mean be “merges together”, but multiple devices can for sure use the same RD and/or T-STUN server. That is how it normally works.

(When you say TURN server, I assume you refer to the T-STUN server. The slides don’t describe the usage of a TURN server/relay, but that would for sure be possible)

>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.

Not sure I understand. The T-STUN server only provides the public IP address:port of the device. The device creates the URI.

>Can we find any document elaborating these slides?

At the moment there is no IETF draft describing this, mostly because so far people haven’t shown too much interest in it.

It is described in my thesis, so if you want I can give you the link for that :)

>And, is there any opensource implementation available of this proposal please?

Currently not, unfortunately, as far as I know.



On Fri, Apr 3, 2020 at 12:11 AM Christer Holmberg <<>> wrote:

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 <<>> on behalf of Abhijan Bhattacharyya <<>>
Date: Thursday, 2 April 2020 at 11.04
To: Thomas Fossati <<>>
Cc: core <<>>
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?


On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati <<>> wrote:
Hi Abhijan,

On 01/04/2020, 12:31, Abhijan Bhattacharyya <<>> 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.


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.

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

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