[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/>