Re: [core] CoAP over TCP

Ben Kinsella <bkinsella@bb-elec.com> Thu, 26 February 2015 14:55 UTC

Return-Path: <bkinsella@bb-elec.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744911A0211 for <core@ietfa.amsl.com>; Thu, 26 Feb 2015 06:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.399
X-Spam-Level: *
X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 WWYJ4OsVnmcm for <core@ietfa.amsl.com>; Thu, 26 Feb 2015 06:55:57 -0800 (PST)
Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2141A0162 for <core@ietf.org>; Thu, 26 Feb 2015 06:55:57 -0800 (PST)
Received: from smtp2.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 888C0180439 for <core@ietf.org>; Thu, 26 Feb 2015 09:55:56 -0500 (EST)
Received: from smtp192.mex07a.mlsrvr.com (unknown [67.192.133.128]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTPS id 68B3318047C for <core@ietf.org>; Thu, 26 Feb 2015 09:55:56 -0500 (EST)
X-Sender-Id: bkinsella@bb-elec.com
Received: from smtp192.mex07a.mlsrvr.com ([UNAVAILABLE]. [67.192.133.128]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:25 (trex/5.4.2); Thu, 26 Feb 2015 14:55:56 GMT
Received: from DFW1MBX04.mex07a.mlsrvr.com ([169.254.2.188]) by DFW1HUB15.mex07a.mlsrvr.com ([::1]) with mapi; Thu, 26 Feb 2015 08:55:45 -0600
From: Ben Kinsella <bkinsella@bb-elec.com>
To: "core@ietf.org" <core@ietf.org>
Date: Thu, 26 Feb 2015 08:55:45 -0600
Thread-Topic: Re: [core] CoAP over TCP
Thread-Index: AdBR1ApwgnIx4ABnT1yxd2pmumt+7g==
Message-ID: <7221955A65891E4C90CEF9A551B5633E564E095C1B@DFW1MBX04.mex07a.mlsrvr.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/CN_vDYMj6JDrqMoyXAkObnWtPWc>
X-Mailman-Approved-At: Thu, 26 Feb 2015 09:43:23 -0800
Subject: Re: [core] CoAP over TCP
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 26 Feb 2015 14:55:58 -0000

Hi.

Apologies for resurrecting this thread, but I haven't seen any updates on this topic since November.

>> 3) CoAP over TCP.  draft-bormann-core-coap-tcp-01 is a summary of the
>> design choices. draft-tschofenig-core-coap-tcp-tls selects one option
>> without explaining why.
>
>draft-tschofenig-core-coap-tcp-tls describes what we (ARM and Zebra)
>have implemented and deployed.

draft-bormann-core-coap-tcp expired in January, and draft-tschofenig-core-coap-tcp-tls is due to expire next week.
Please excuse my ignorance of how the IETF process works, but my understanding was that the IETF would standardise on one approach for CoAP over TCP.
Is this still going to happen?

My interest is in the use of CoAP and LWM2M over cellular networks, and I have some concerns over the use of UDP in scenarios which do not support VPNs or private APNs.
Can anyone provide real-world examples of the successful use of CoAP over UDP in this type of environment?
For example, my understanding is that LWM2M already makes a slight modification to CoAP in order to get around the cellular NAT issue: the device initiates the connection to the head-end.
Is UDP as the transport simply not an issue, and therefore there is no real motivation for CoAP over TCP?

I was hoping that IETF standardisation of CoAP over TCP would also trigger changes in OMA's LWM2M spec.
For example, if I adopt the ARM approach outlined in draft-tschofenig-core-coap-tcp-tls, I presume I cannot use a standard LWM2M server?
In what scenarios is the ARM/Zebra approach used?

Alternatively, I know that there are also efforts underway to add an MQTT binding to LWM2M, as an alternative to CoAP.
Which is likely to reach standardisation first: CoAP over TCP, or LWM2M over MQTT?

Regards,
Ben.

Ben Kinsella | Senior Engineer
B+B SmartWorx | Westlink Commercial Park, Oranmore, Co. Galway, Ireland
Office: +353 91 792444 | 
Email: bkinsella@bb-smartworx.com | bb-smartworx.com
Skype: ben.kinsella | ie.linkedin.com/in/benkinsella/


Hannes Tschofenig | 11 Nov 00:33 2014
Re: CoAP over TCP

Hi Carsten,

thanks for the write-up.

On 10/24/2014 06:11 PM, Carsten Bormann wrote:
> In alternative transports, I believe we have three hot topics:
> 
> 1) General issues.  draft-silverajan-core-coap-alternative-transports
> is a good basis for this and we will do the call for adoption soon.
> 
> 2) CoAP over SMS.  This is also related to the question of DTLS over
> SMS.  We have a good draft for the former, which is mostly waiting
> for (1).  draft-fossati-dtls-over-gsm-sms merits some discussion.

Thanks for mentioning draft-fossati-dtls-over-gsm-sms; I am happy to
briefly describe what we had been working on.

> 
> 3) CoAP over TCP.  draft-bormann-core-coap-tcp-01 is a summary of the
> design choices. draft-tschofenig-core-coap-tcp-tls selects one option
> without explaining why.

draft-tschofenig-core-coap-tcp-tls describes what we (ARM and Zebra)
have implemented and deployed.

Our use case is firewall traversal in enterprise networks. Our goal was
to use our existing CoAP over UDP implementation. Doing optimizations to
CoAP when we already add all the complexity of TCP didn't seem
worthwhile to us.

Ciao
Hannes