Re: [core] CoAP over TCP

Simon Lemay <simon.lemay@gmail.com> Wed, 12 November 2014 00:22 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 D989C1A8A1F for <core@ietfa.amsl.com>; Tue, 11 Nov 2014 16:22:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 MPRXZuVh-_ET for <core@ietfa.amsl.com>; Tue, 11 Nov 2014 16:22:25 -0800 (PST)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C640E1A8A4D for <core@ietf.org>; Tue, 11 Nov 2014 16:22:24 -0800 (PST)
Received: by mail-pa0-f47.google.com with SMTP id kx10so11679784pab.34 for <core@ietf.org>; Tue, 11 Nov 2014 16:22:24 -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 :content-transfer-encoding:message-id:references:to; bh=STLISJnYm+xx+iqnJ9qpwdXU85Y18ExYSSq4kiQiaAI=; b=Jh/h8YQsZMtTJTeSfbd3dp0rXma8U0XEROx3ga6gG5a54N1ks9pIgyRkLa/b0fGIVU Ui8I2XXXtiN+C/qpjH4waoDRSyHx+ipBy9XMFq2zIMjK2NluOSXHV6BCuPl0DSSr78LX Wbze0W+IGJjSXorcl/MlJJRtsT5mi1Gas1IYBC7d1RJIraQLGM0ikgpSEwv8Szzv+7J7 FqXrN9ULQinEoo+WApdya2Mup81Pe9uciHHdPZRz/qU6IY2QqLtDmjIorgNU1sRedCMC VNq/qPMYOjQiUcw8snEZHHS6kMiZeeM3DA7KSE8RMH54OaFdOqu3K2yGIABy6i6a69nT aPlA==
X-Received: by 10.66.65.169 with SMTP id y9mr20424259pas.102.1415751744030; Tue, 11 Nov 2014 16:22:24 -0800 (PST)
Received: from simons-mbp.lan ([166.170.49.85]) by mx.google.com with ESMTPSA id y2sm20428650pdp.31.2014.11.11.16.22.22 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 16:22:23 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Simon Lemay <simon.lemay@gmail.com>
In-Reply-To: <BF7249EB-52D2-4DDC-8AF7-276FEFB3C4E8@tzi.org>
Date: Tue, 11 Nov 2014 14:22:21 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <B258D2D0-D2DD-43F8-B5A6-1C94EDDD6979@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> <FAC811D4-AD91-40C1-AC50-2297F93A76D1@gmail.com> <BF7249EB-52D2-4DDC-8AF7-276FEFB3C4E8@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/core/8_gKgCqsxOzZs8KMBj6ELNREPMY
Cc: "core@ietf.org WG" <core@ietf.org>
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: Wed, 12 Nov 2014 00:22:28 -0000

Hi Carsten, 

Thanks for you reply, these are very good point, 

For the Resilience, this is a good point and would require some more work,  With no security it is feasible with the Endpoint information, but its does get more complicated when adding a security mode.

So aside from that, we could enforce the MessageID and and chosen Message type semantic in all cases (as it is right now for UDP) hence insuring the information is retransmitted.  It would be either that or enforcing to ignore the field without removing them in the case of TCP, the latter one tho creates a switch case base on the transport layer which i believe would be undesirable and would create in my opinion more confusion than it would be helpful.

Simon Lemay


> On Nov 10, 2014, at 4:52 PM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> On 10 Nov 2014, at 16:06, Simon Lemay <simon.lemay@gmail.com> wrote:
>> 
>> - if TCP is chosen, we can assume that payload size is not the main concern, hence keeping unused field probably won’t cause problems
> 
> As I said in the previous message (http://www.ietf.org/mail-archive/web/core/current/msg05748.html), the number of bytes consumed by the fields is not the only consideration, but in particularly the question whether they continue to carry their UDP semantics or not.
> 
> If you want to go for the resilient variant (https://tools.ietf.org/html/draft-bormann-core-coap-tcp-01#section-3.5), that changes everything, of course.  How do you propose to link TCP connections to each other (i.e., how do I know whether a TCP connection I have is good for sending a response to a message that was sent on another TCP connection)?
> 
> Grüße, Carsten
>