Re: [core] CoAP for high throughput applications
"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Wed, 06 April 2016 09:58 UTC
Return-Path: <carlesgo@entel.upc.edu>
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 1901212D874 for <core@ietfa.amsl.com>; Wed, 6 Apr 2016 02:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 1myg4clenQQl for <core@ietfa.amsl.com>; Wed, 6 Apr 2016 02:58:53 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA2012D177 for <core@ietf.org>; Wed, 6 Apr 2016 02:58:52 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id u369wmIx010356; Wed, 6 Apr 2016 11:58:48 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 02B001D53C1; Wed, 6 Apr 2016 11:58:48 +0200 (CEST)
Received: from 131.111.5.14 by webmail.entel.upc.edu with HTTP; Wed, 6 Apr 2016 11:58:38 +0200
Message-ID: <54c26e6d388f0ea0564417ffc87a4091.squirrel@webmail.entel.upc.edu>
In-Reply-To: <D328743C.62C97%thomas.fossati@alcatel-lucent.com>
References: <D32866D3.62C58%thomas.fossati@alcatel-lucent.com> <5702E93E.3030005@tzi.org> <D328743C.62C97%thomas.fossati@alcatel-lucent.com>
Date: Wed, 06 Apr 2016 11:58:38 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Mail-Scanned: Criba 2.0 + Clamd
X-Greylist: Delayed for 24:13:48 by milter-greylist-4.4.3 (dash.upc.es [147.83.2.50]); Wed, 06 Apr 2016 11:58:49 +0200 (CEST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/4sBRTn2yVJhEa79mImo6_dNi1fI>
Cc: ilker.demirkol@entel.upc.edu, august.betzler@googlemail.com, "core@ietf.org" <core@ietf.org>
Subject: Re: [core] CoAP for high throughput applications
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 06 Apr 2016 09:58:57 -0000
Hi Thomas, >>> Now, a single LURK box could have to handle lots of these requests, >>> potentially in thousands per second, whereas CoAP's default congestion >>> control algorithm parameters [3] are, by design, way too conservative >>> to >>> be suitable for high-throughput use cases. >> >>That would be an interesting application for CoCoA... > > Is CoCoA available if I'd want to test it? Here you may find the Californium implementation including CoCoA: https://github.com/eclipse/californium As Matthias said, the implementation including CoCoA is not actually optimized for dealing with thousands of requests. However, CoCoA is adaptive and, if network conditions allow it, the algorithm may behave more aggressively than default CoAP's congestion control (while still being safe). In the experiments we have done so far, we have dealt with up to hundreds of requests per second (outperforming default CoAP and also state-of-the-art alternative approaches designed for TCP), since the limitation in our scenarios was the network/channel capacity (e.g. [1, 2]). It would be very interesting to see what happens in a scenario such as the one you describe, where the limitation might not be the network throughput. By the way, feedback on CoCoA would be very much welcome! Thanks, Carles [1] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP congestion control for the Internet of Things", IEEE Communications Magazine (In press). https://www.researchgate.net/publication/297989374_CoAP_Congestion_Control_for_the_Internet_of_Things [2] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoCoA+: an advanced congestion control mechanism for CoAP", Ad-hoc Networks journal, 2015. http://www.sciencedirect.com/science/article/pii/S1570870515000888
- [core] CoAP for high throughput applications Fossati, Thomas (Nokia - GB)
- Re: [core] CoAP for high throughput applications Carsten Bormann
- Re: [core] CoAP for high throughput applications Zach Shelby
- Re: [core] CoAP for high throughput applications Fossati, Thomas (Nokia - GB)
- Re: [core] CoAP for high throughput applications Fossati, Thomas (Nokia - GB)
- Re: [core] CoAP for high throughput applications Kovatsch Matthias
- Re: [core] CoAP for high throughput applications Carsten Bormann
- Re: [core] CoAP for high throughput applications Fossati, Thomas (Nokia - GB)
- Re: [core] CoAP for high throughput applications Carles Gomez Montenegro
- Re: [core] CoAP for high throughput applications Fossati, Thomas (Nokia - GB)