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