Re: [core] CoAP over TCP

Simon Lemay <simon.lemay@gmail.com> Tue, 11 November 2014 02:06 UTC

Return-Path: <simon.lemay@gmail.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 6145E1AD3F5 for <core@ietfa.amsl.com>; Mon, 10 Nov 2014 18:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, 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 rMqlMA_QUB-Y for <core@ietfa.amsl.com>; Mon, 10 Nov 2014 18:06:54 -0800 (PST)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637AB1ACD5F for <core@ietf.org>; Mon, 10 Nov 2014 18:06:45 -0800 (PST)
Received: by mail-pd0-f171.google.com with SMTP id r10so9051872pdi.16 for <core@ietf.org>; Mon, 10 Nov 2014 18:06:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GKHEBLNo0UNmzIkubNKjTGb+rSL1lRYvOU8pR8lGQZ4=; b=EABF9SQggJbQZ3efBmVJiCuDo15n4T9UEZZouthVAroV1k5q3muJ32S3iv+g8gjATN cSHAK2fa2TreCGTTHA2cM55XlgUXo1unzr7tNHwBB5GwXL/UsMoNdKc00oz4zwF4Q64C ZK9koMxMKttzkS0uKWMA48P61lJ5Oz1Friq27eWTHAULjF3fIGgbLIWXZCcEg6oZN03D kGxHRPqKAdO+F8GTl0QjuJJblSzl63CgimMl68DGFWLC4xq9c9xgGPHzV4AocirKDrdf Dgvb+RLjPKekRFa5RJnYdVkezv2bQ3vbT5opja47By2oS3eMG7ZmJRyy1zsuIPl3Iqrx tSXg==
X-Received: by 10.70.44.99 with SMTP id d3mr36495637pdm.46.1415671604573; Mon, 10 Nov 2014 18:06:44 -0800 (PST)
Received: from simons-mbp.lan ([166.170.48.43]) by mx.google.com with ESMTPSA id yl6sm17631336pbc.91.2014.11.10.18.06.42 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 18:06:43 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B35D3884-FEFF-4CB6-BDB8-6C21DDF8A2F5"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Simon Lemay <simon.lemay@gmail.com>
In-Reply-To: <03A02BCF-9C78-4A0F-A529-E3D6FFF795C5@tzi.org>
Date: Mon, 10 Nov 2014 16:06:40 -1000
Message-Id: <FAC811D4-AD91-40C1-AC50-2297F93A76D1@gmail.com>
References: <EAEFE980-6DDA-4616-AEB0-AF1D23A6E552@tzi.org> <5E6DADEA-2A1B-4E38-AF83-D1ACB4C30428@tzi.org> <D0869870.3966%randy.turner@landisgyr.com> <03A02BCF-9C78-4A0F-A529-E3D6FFF795C5@tzi.org>
To: "core@ietf.org WG" <core@ietf.org>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/core/2hFR9iCvGDAj7j4QBZdl8wUHLS0
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: Tue, 11 Nov 2014 02:06:59 -0000

Hi Carsten,

In the case of CoAP over TCP, i do like the approach of a simple fixed length header for a few reason,

- it keep coap "as is", meaning that there is no need to have different de/serializer then those who already exists.  And since CoAP makes an effort to have both client and server use the same serialization process, it would be to carry that when implementing on other transport layer.
- if TCP is chosen, we can assume that payload size is not the main concern, hence keeping unused field probably won’t cause problems
- Also, as mentioned in https://tools.ietf.org/html/draft-bormann-core-coap-tcp-01 <https://tools.ietf.org/html/draft-bormann-core-coap-tcp-01> section 3.5, i would agree that is is a likely scenario, and keeping the CoAP structure as is will help with silent behavioral device, or device in low latency area who might not want to keep a connection alive for long periods of time or have intermittent connection.
-it would also help to abstract the under layer and help a more dynamic switching of the transport layer

In the case of 2 or 4 byte long, i do agree that 2 byte might be sufficient but and 4 byte would help avoid second degree fragmentation on bigger message (most likely from not so constraint device, attach to a power source).  I am undecided as to would be the best option.

Thanks

Simon

> On Nov 10, 2014, at 2:01 PM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> Hi Randy,
> 
> indeed, CoAP is designed for situations where constrained nodes are involved.
> This does not mean, however, that the other node also needs to be constrained, or that we can’t have cloud-side infrastructure that processes CoAP interchanges.
> Converting to HTTP is certainly an option, but why convert if the other node speaks CoAP, too.
> 
> Grüße, Carsten
> 
>> On 10 Nov 2014, at 11:32, Turner, Randy <Randy.Turner@landisgyr.com> wrote:
>> 
>> 
>> Hi Carsten,
>> 
>> I wasn¹t aware that CoAP would exist (in any significant way) ³outside² of
>> constrained environments ‹ I¹ve been thinking HTTP<->CoAP gateways at the
>> edge of a constrained environment - only using ³CoAP² where the ³Co²
>> requirement exists.  I¹m assuming CoAP in the cloud would only be for
>> ³IoT-only² services ?
>> 
>> Thanks!
>> Randy
>> 
>> On 11/10/14, 3:24 PM, "Carsten Bormann" <cabo@tzi.org> wrote:
>> 
>>> One more data point that came up in the APPAREA WG this morning:
>>> 
>>> Sam Ruby has now started an effort to find out how URI parsers actually
>>> behave.
>>> I¹m not sure that is the best link, but if interested maybe you can start
>>> looking at
>>> http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI
>>> 
>>> Grüße, Carsten
>>> 
>>> 
>>>> On 24 Oct 2014, at 06:11, Carsten Bormann <cabo@tzi.org> 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.
>>>> 
>>>> 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-savolainen-core-coap-websockets (apart
>>>> from being focused on web sockets, so it would need the addition of a
>>>> length field) selects a different set of options, also not really
>>>> explaining why.  This merits a discussion.
>>>> 
>>>> I believe we should have a quick round of discussion about (3).  CoAP
>>>> over TCP is of strong interest to people building scalable cloud-side
>>>> CoAP implementations.  CoAP over TCP also is a NAT traversal strategy
>>>> (where the server builds the connection to a client in the cloud).
>>>> Finally, CoAP over TCP can be useful to combine the better congestion
>>>> control of TCP with the economy of CoAP.  So there are enough reasons to
>>>> get this going.
>>>> 
>>>> The main questions I see are:
>>>> 
>>>> a) what is the delimiting mechanism?
>>>> ‹ length field
>>>>   ‹ fixed 4-byte, fixed 2-byte, variable?
>>>> ‹ MINION-style (delimiters)
>>>> ‹ extending the payload marker
>>>> b) what part of the CoAP header remains active over a reliable
>>>> transport?  Can we lose
>>>> ‹ the message id,
>>>> ‹ the message type,
>>>> ‹ the version number?
>>>> c) any negotiation/version indication mechanisms?
>>>> ‹ starttls???
>>>> ‹ server/client prompts
>>>> ‹ ALPN
>>>> ‹ other payloads, e.g. stream errors?
>>>> 
>>>> Grüße, Carsten
>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>> 
>> 
>> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
>> 
>> This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core