[core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach
"core issue tracker" <trac+core@zinfandel.tools.ietf.org> Sat, 26 March 2016 15:55 UTC
Return-Path: <trac+core@trac.tools.ietf.org>
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 9309712D55A for <core@ietfa.amsl.com>; Sat, 26 Mar 2016 08:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 vNGA8w3lMiJJ for <core@ietfa.amsl.com>; Sat, 26 Mar 2016 08:55:51 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B190E12D1E4 for <core@ietf.org>; Sat, 26 Mar 2016 08:55:51 -0700 (PDT)
Received: from localhost ([::1]:52011 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+core@trac.tools.ietf.org>) id 1ajqZ5-0007Rm-8R; Sat, 26 Mar 2016 08:55:51 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: core issue tracker <trac+core@zinfandel.tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: hannes.tschofenig@gmx.net, Hannes.Tschofenig@gmx.net
X-Trac-Project: core
Date: Sat, 26 Mar 2016 15:55:51 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/396
Message-ID: <065.8fdd76888850930554160d95484c0360@trac.tools.ietf.org>
X-Trac-Ticket-ID: 396
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hannes.tschofenig@gmx.net, Hannes.Tschofenig@gmx.net, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/eGFP4qRvqYM47TwI0tGL5KyjZ1g>
Cc: core@ietf.org
Subject: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
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: Sat, 26 Mar 2016 15:55:53 -0000
#396: L1 vs. L3 Encoding Approach Copy-and-paste from the mailing list: http://www.ietf.org/mail-archive/web/core/current/msg06905.html At the T2TRG meeting, which took place the two days before the IAB IOTSI workshop in Santa Clara, we met with various OIC/OCF guys and talked about ongoing IoT standardization work in the IETF/IRTF as well as in the OIC/OCF. We learned that they have selected a different solution approach for CoAP over TCP: we have selected option L1 from Section 4 of https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04 and they have selected option L3. In an off-list mail exchange we also received information about the performance investigations they have done. Here is what we got: > For 4MB data, the transmission time is > > 1. CoAP over TCP L1 + BWT : 70 s > > 2. CoAP over TCP L3 : 1.7 s (BWT = Block-Wise Transfer) We have not taken the performance aspect of larger file transfers (e.g., transfer of a 4MB firmware update) into account when we made the solution decision in Yokohama. The reason why the OIC/OCF take such large file transfers into account is because of their desire to use CoAP also for non-constrained devices. I believe it would be good to verify / analyse the performance analysis of the OIC/OCF guys. In particular, it would be reasonable to compare the performance of option L1 and option L3 from Section 4 of https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04 with a CoAP protocol stack, such as Californium and the mbed CoAP library. Carsten pointed out that L1 is limited to 64 KiB (which is further reduced by Block's current largest block size of 1 KiB in the analysis above), while L3 allows for larger payloads. Of course, we may not need to use Block Transfer in CoAP when we already use CoAP over TCP. -- -------------------------------------+------------------------------------- Reporter: | Owner: Hannes.Tschofenig@gmx.net | hannes.tschofenig@gmx.net Type: other technical | Status: new Priority: major | Milestone: Component: coap-tcp-tls | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/396> core <https://tools.ietf.org/core/>
- [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Ap… core issue tracker
- Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encodin… Carsten Bormann
- Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encodin… Abhijan Bhattacharyya
- Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encodin… core issue tracker
- Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encodin… core issue tracker