From Richard.Kelsey@silabs.com  Mon Jan  6 08:56:42 2014
Return-Path: <Richard.Kelsey@silabs.com>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B76D1AE0E8 for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 08:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 HEZ5D9XM30FN for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 08:56:40 -0800 (PST)
Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA851AE0EF for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 08:56:40 -0800 (PST)
Received: from mxsause01.silabs.com ([66.193.122.70]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKUsrgOG+EIdeXtaFrPWo8S8oT8cVF6B9h@postini.com; Mon, 06 Jan 2014 08:56:32 PST
Received: from EXCAUS010.silabs.com (unknown [10.100.0.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mxsause01.silabs.com (Postfix) with ESMTP id A3049FF0AF for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 10:56:17 -0600 (CST)
Received: from kelsey-ws (10.4.148.34) by EXCAUS010.silabs.com (10.100.0.59) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 6 Jan 2014 10:56:17 -0600
Date: Mon, 6 Jan 2014 12:02:25 -0500
Message-ID: <87txdhdowu.fsf@kelsey-ws.hq.ember.com>
From: Richard Kelsey <richard.kelsey@silabs.com>
To: <dtls-iot@ietf.org>
In-Reply-To: <30208.1387380214@sandelman.ca> (message from Michael Richardson on Wed, 18 Dec 2013 10:23:34 -0500)
X-Auto-Response-Suppress: DR, OOF, AutoReply
References: <CADZyTkmF=WOVgQrUD6u3rObe7vyXdN+YsyMyBcGXbj2Hi--qrw@mail.gmail.com> <30208.1387380214@sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain
X-Originating-IP: [10.4.148.34]
Subject: Re: [Dtls-iot] 32 bit alignment with IoT
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 16:56:42 -0000

> From: Michael Richardson <mcr at sandelman.ca>
> Date: Wed, 18 Dec 2013 10:23:34 -0500
> 
> Padding sent as zeroes is pretty easy to compress out if one is compressing
> generically.  I've advocated for doing sensible protocol design, leaving
> ourselves appropriate places to introduce new values, and look at what the
> byte count is after some naive, trivial compression as provided by 6lowpan HC
> and GHC.

GHC is good at compressing out blocks of zeroes.  It doesn't do
anything with single zero bytes, which 16-bit alignment of small
values produces.  For example, DCHPv6 has a lot of 16-bit fields
where the high byte is zero.  GHC doesn't help.

Also, having implemented GHC, I don't consider it trivial.  You
either have to write generic compression code, which consumes a
chunk of RAM and/or CPU cycles, or build GHC into the protocol
implementation, which adds more complexity.  If a protocol is
intended for the IoT then we should keep it compact and not rely
on GHC or other compression scheme.

                                       -Richard
This email and any attachments may be confidential. If so, do not disseminate without the sender’s authorization. If you are not the intended recipient, please delete it and notify the sender. Email transmissions cannot be guaranteed to be error-free or virus-free and we accept no liability. Silicon Labs does not intend or authorize emails to act as legally binding contracts.


From cabo@tzi.org  Mon Jan  6 12:28:59 2014
Return-Path: <cabo@tzi.org>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0C1AE1F9 for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 12:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 uh0QT-IJSANJ for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 12:28:58 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 08A051AE1F6 for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 12:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s06KSgn0003487; Mon, 6 Jan 2014 21:28:43 +0100 (CET)
Received: from [192.168.217.101] (p54891CFE.dip0.t-ipconnect.de [84.137.28.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0E36ABBF; Mon,  6 Jan 2014 21:28:41 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <87txdhdowu.fsf@kelsey-ws.hq.ember.com>
Date: Mon, 6 Jan 2014 21:28:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <464E3994-EEAC-47CB-B095-F45411BBA65B@tzi.org>
References: <CADZyTkmF=WOVgQrUD6u3rObe7vyXdN+YsyMyBcGXbj2Hi--qrw@mail.gmail.com> <30208.1387380214@sandelman.ca> <87txdhdowu.fsf@kelsey-ws.hq.ember.com>
To: Richard Kelsey <richard.kelsey@silabs.com>
X-Mailer: Apple Mail (2.1827)
Cc: dtls-iot@ietf.org
Subject: Re: [Dtls-iot] 32 bit alignment with IoT
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 20:29:00 -0000

> GHC is good at compressing out blocks of zeroes.  It doesn't do
> anything with single zero bytes, which 16-bit alignment of small
> values produces.  For example, DCHPv6 has a lot of 16-bit fields
> where the high byte is zero.  GHC doesn't help.

Indeed.  I considered adding something like a predictor byte code (which =
carries a bitfield saying which of the following uncompressed bytes are =
zero, as in RFC 2687=92s FSE construction).
I didn=92t come up with anything that was a real improvement with my =
current corpus, so I left it out.
But I=92m not claiming I examined the entire design space =97 I don=92t =
have a good corpus of DHCPv6 packets to work with (hint, hint).

> Also, having implemented GHC, I don't consider it trivial. =20

Well, it is trivial compared to, say, RFC 1951, but it is still LZ =
compression.
There also is a =93low-hanging fruit=94 style implementation technique =
for the compressor, maybe something for LWIG to document.
The decompressor, though, should indeed be trivial (but does need a =
second buffer).

I completely agree that is is better to shoot for compact protocol =
encodings in the first place than to fix garrulous encodings after the =
fact by compression.  But we do have a few of the latter that aren=92t =
going away.

Gr=FC=DFe, Carsten


From msj@nthpermutation.com  Mon Jan  6 14:27:53 2014
Return-Path: <msj@nthpermutation.com>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03B1AE293 for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 14:27:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Qp-PDggfrAmh for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 14:27:52 -0800 (PST)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id C5E271AE291 for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 14:27:51 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id m20so18305790qcx.32 for <dtls-iot@ietf.org>; Mon, 06 Jan 2014 14:27:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=umQOg5NiEpCrAkiOq9YCZXuS2P8DcXEVGvf98Mciglk=; b=UgC4V02Rndflw9Pwbpta7NNUpDm68I4tRZRzNUln2FxEudPGqovvwXnNZCabVvJwlE ecXSODSZCoJcwGqbOPFV99YRddnRJixsFP2/DDyB1rr7ZyabD5Lz3PnoFf/LOQubBay5 fc5KrYL6r7f1hK+bPF9we3n19Y366n8Kvlds2fH6GymWH5xC000cOMjuIZhEGWb9PJit q5UyR0lz5JSTr/VrTkDZ2CPOR+f4Y6+tX5M3ya6JCLB2V/ywWDldnJ9cqEceIvdGUmqF Sj65HS+KHjzt2Aq07OgzFx/X5PMujbryX76fKol4Qp4kTficD73KBrwhnRAcnI5SNa83 irig==
X-Gm-Message-State: ALoCoQnTqtmpaPix8TTUtGD0P8e9ANqP5CK7xOmyPnZ9Z1veb9i0IHQIR0Z0TQPtiof4BBo+4iH6
X-Received: by 10.229.105.9 with SMTP id r9mr181081687qco.12.1389047263045; Mon, 06 Jan 2014 14:27:43 -0800 (PST)
Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id q2sm97076694qer.22.2014.01.06.14.27.42 for <dtls-iot@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 14:27:42 -0800 (PST)
Message-ID: <52CB2DDC.7040602@nthpermutation.com>
Date: Mon, 06 Jan 2014 17:27:40 -0500
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dtls-iot@ietf.org
References: <CADZyTkmF=WOVgQrUD6u3rObe7vyXdN+YsyMyBcGXbj2Hi--qrw@mail.gmail.com> <30208.1387380214@sandelman.ca> <87txdhdowu.fsf@kelsey-ws.hq.ember.com> <464E3994-EEAC-47CB-B095-F45411BBA65B@tzi.org>
In-Reply-To: <464E3994-EEAC-47CB-B095-F45411BBA65B@tzi.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Dtls-iot] 32 bit alignment with IoT
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 22:27:53 -0000

Are we trying to solve the wrong problem?  E.g. the trade off is between 
processing time (and energy) and transmission time (and energy).  So any 
reduction of the energy used for transmission, is probably going to be 
somewhat offset by the cost of compression.  The question then becomes 
is it worth it to spend the time (and engineering cycles) in this space 
for a small reduction in transmitted bits?

Mike


On 1/6/2014 3:28 PM, Carsten Bormann wrote:
>> GHC is good at compressing out blocks of zeroes.  It doesn't do
>> anything with single zero bytes, which 16-bit alignment of small
>> values produces.  For example, DCHPv6 has a lot of 16-bit fields
>> where the high byte is zero.  GHC doesn't help.
> Indeed.  I considered adding something like a predictor byte code (which carries a bitfield saying which of the following uncompressed bytes are zero, as in RFC 2687’s FSE construction).
> I didn’t come up with anything that was a real improvement with my current corpus, so I left it out.
> But I’m not claiming I examined the entire design space — I don’t have a good corpus of DHCPv6 packets to work with (hint, hint).
>
>> Also, having implemented GHC, I don't consider it trivial.
> Well, it is trivial compared to, say, RFC 1951, but it is still LZ compression.
> There also is a “low-hanging fruit” style implementation technique for the compressor, maybe something for LWIG to document.
> The decompressor, though, should indeed be trivial (but does need a second buffer).
>
> I completely agree that is is better to shoot for compact protocol encodings in the first place than to fix garrulous encodings after the fact by compression.  But we do have a few of the latter that aren’t going away.
>
> Grüße, Carsten
>
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot


From cabo@tzi.org  Mon Jan  6 14:44:28 2014
Return-Path: <cabo@tzi.org>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36E1AE29A for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 14:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 NFQwTsTvCNUh for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 14:44:27 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 83FD21AD8EA for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 14:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s06MiH2R021436; Mon, 6 Jan 2014 23:44:17 +0100 (CET)
Received: from [192.168.217.105] (p54891CFE.dip0.t-ipconnect.de [84.137.28.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 70A3CC10; Mon,  6 Jan 2014 23:44:16 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52CB2DDC.7040602@nthpermutation.com>
Date: Mon, 6 Jan 2014 23:44:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1FB3E40-5BFD-4D30-8181-3AD35ADAE328@tzi.org>
References: <CADZyTkmF=WOVgQrUD6u3rObe7vyXdN+YsyMyBcGXbj2Hi--qrw@mail.gmail.com> <30208.1387380214@sandelman.ca> <87txdhdowu.fsf@kelsey-ws.hq.ember.com> <464E3994-EEAC-47CB-B095-F45411BBA65B@tzi.org> <52CB2DDC.7040602@nthpermutation.com>
To: Michael StJohns <msj@nthpermutation.com>
X-Mailer: Apple Mail (2.1827)
Cc: dtls-iot@ietf.org
Subject: Re: [Dtls-iot] 32 bit alignment with IoT
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 22:44:28 -0000

On 06 Jan 2014, at 23:27, Michael StJohns <msj@nthpermutation.com> =
wrote:

> The question then becomes is it worth it to spend the time (and =
engineering cycles) in this space for a small reduction in transmitted =
bits?

Among other things (payload sizes etc.), the answer depends on the =
garrulity of the legacy protocol.

For DTLS 1.2 (with our current cipher suites) in 6LoWPAN applications, =
I=92m pretty sure the answer is a resounding YES.
If DTLS 1.3 goes right, this may become less obvious.
(For IPv6 and UDP headers, the answer is so obviously yes that RFC 6282 =
is a mandatory part of 6LoWPAN, and we are even considering getting rid =
of the uncompressed option.)

Gr=FC=DFe, Carsten


From mcr@sandelman.ca  Mon Jan  6 15:22:19 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6F1AE2F2 for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 15:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.009
X-Spam-Level: *
X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] 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 ru7m0ZzUxMG7 for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 15:22:18 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE931AE2EC for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 15:22:18 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 92B2E2003F for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 19:37:24 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 39ED864647; Mon,  6 Jan 2014 18:22:09 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 26CB463AD7 for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 18:22:09 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dtls-iot@ietf.org
In-Reply-To: <464E3994-EEAC-47CB-B095-F45411BBA65B@tzi.org>
References: <CADZyTkmF=WOVgQrUD6u3rObe7vyXdN+YsyMyBcGXbj2Hi--qrw@mail.gmail.com> <30208.1387380214@sandelman.ca> <87txdhdowu.fsf@kelsey-ws.hq.ember.com> <464E3994-EEAC-47CB-B095-F45411BBA65B@tzi.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 06 Jan 2014 18:22:09 -0500
Message-ID: <24899.1389050529@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Dtls-iot] 32 bit alignment with IoT
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 23:22:20 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Carsten Bormann <cabo@tzi.org> wrote:
    >> Also, having implemented GHC, I don't consider it trivial.

    > Well, it is trivial compared to, say, RFC 1951, but it is still LZ
    > compression.  There also is a =E2=80=9Clow-hanging fruit=E2=80=9D sty=
le implementation
    > technique for the compressor, maybe something for LWIG to document.
    > The decompressor, though, should indeed be trivial (but does need a
    > second buffer).

https://github.com/mcr/roll-ghc/blob/master/ghc.c
is 118 lines.... I didn't know how to use the contexts, so I didn't.

With only this code only, I was able to match the manually "compressed"
(optimized) version of ROLL DIO messages, fitting the result into a single
15.4 frame.

    > I completely agree that is is better to shoot for compact protocol
    > encodings in the first place than to fix garrulous encodings after the
    > fact by compression.  But we do have a few of the latter that aren=E2=
=80=99t
    > going away.

I moderately agree with this statement slightly.

=2D-
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUBUss6noqHRg3pndX9AQJZyQP/dpgRckWxJ5ZmxRRkvx8xs6WWWcb2XGvJ
Ok1c+ZG19gJVJJZVfSOcaoAnbsI9dmc0ZsO2TdvWZVGeebZlyr/dXqb7Sd0uGGgI
N/8f2M+a/ltckQG0cEzajhh/KB81FDe5BDkjLLqqmrmPaoqfGUl5ecGlXrV4TZuV
kaNT8B/w+Qs=
=Tcky
-----END PGP SIGNATURE-----
--=-=-=--

From mcr@sandelman.ca  Mon Jan  6 15:27:18 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F6A1AE304 for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 15:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.019
X-Spam-Level: *
X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] 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 DX2kGROqFXYr for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 15:27:11 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id EEBE91AE2F9 for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 15:27:10 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B305320040 for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 19:42:17 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 5C04764647; Mon,  6 Jan 2014 18:27:02 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 49B2563AD7 for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 18:27:02 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dtls-iot@ietf.org
In-Reply-To: <52CB2DDC.7040602@nthpermutation.com>
References: <CADZyTkmF=WOVgQrUD6u3rObe7vyXdN+YsyMyBcGXbj2Hi--qrw@mail.gmail.com> <30208.1387380214@sandelman.ca> <87txdhdowu.fsf@kelsey-ws.hq.ember.com> <464E3994-EEAC-47CB-B095-F45411BBA65B@tzi.org> <52CB2DDC.7040602@nthpermutation.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 06 Jan 2014 18:27:02 -0500
Message-ID: <25903.1389050822@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Dtls-iot] 32 bit alignment with IoT
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 23:27:18 -0000

--=-=-=


Michael StJohns <msj@nthpermutation.com> wrote:
    > Are we trying to solve the wrong problem?  E.g. the trade off is
    > between processing time (and energy) and transmission time (and
    > energy).  So any reduction of the energy used for transmission, is
    > probably going to be somewhat offset by the cost of compression.  The
    > question then becomes is it worth it to spend the time (and engineering
    > cycles) in this space for a small reduction in transmitted bits?

The tradeoff is quite complex.

The transmission cost has some serious step functions: if you need more than
one 15.4 frame,  your cost goes up significantly, because you might have to
stay awake a lot longer to get your packet through, and might have to
retransmit the whole thing from scratch.

CPU cycles, in even the smallest devices are becoming cheaper and cheaper,
but cost of transmit power is not.  That's why we are moving away from
purpose built protocols (like Zwave) to interoperable network protocols, the
NRE for the purpose built protocols is better spent writing compression
algorithms.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUBUss7w4qHRg3pndX9AQKueQQA3HPe19ICbs0pZ9Jds1B3D6QMBvx+pBZJ
/Jl3c2g797WZrBGp2Yd4bbEk5MmoylO3DYwfhRLuHIlKY1cLFRo3LnZAtYpS7Fay
Et0hwK5qP7LH5xYa3smdNMv3di4Vroj70rWk/kAUkw9vbwIZ/e/VxfA06YVUXSq8
+YBwWtn7+mI=
=UE+7
-----END PGP SIGNATURE-----
--=-=-=--

From cabo@tzi.org  Mon Jan  6 23:38:26 2014
Return-Path: <cabo@tzi.org>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8731AE47C for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 23:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 u8OMhaBOwYnQ for <dtls-iot@ietfa.amsl.com>; Mon,  6 Jan 2014 23:38:24 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5971AE46C for <dtls-iot@ietf.org>; Mon,  6 Jan 2014 23:38:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s077c8Fa003044; Tue, 7 Jan 2014 08:38:08 +0100 (CET)
Received: from [192.168.217.105] (p54891941.dip0.t-ipconnect.de [84.137.25.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A7734C81; Tue,  7 Jan 2014 08:38:07 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <24899.1389050529@sandelman.ca>
Date: Tue, 7 Jan 2014 08:38:06 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <661F1424-20D1-4182-932B-93BA698302D8@tzi.org>
References: <CADZyTkmF=WOVgQrUD6u3rObe7vyXdN+YsyMyBcGXbj2Hi--qrw@mail.gmail.com> <30208.1387380214@sandelman.ca> <87txdhdowu.fsf@kelsey-ws.hq.ember.com> <464E3994-EEAC-47CB-B095-F45411BBA65B@tzi.org> <24899.1389050529@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.1827)
Cc: dtls-iot@ietf.org
Subject: Re: [Dtls-iot] 32 bit alignment with IoT
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2014 07:38:26 -0000

On 07 Jan 2014, at 00:22, Michael Richardson <mcr+ietf@sandelman.ca> =
wrote:

> https://github.com/mcr/roll-ghc/blob/master/ghc.c
> is 118 lines=85.

Nice example of a low-hanging fruit implementation (63 SLOC for the =
actual compressor).

> I didn't know how to use the contexts, so I didn=92t.

The contexts are gone from the current spec, but with more code you =
could use more back referencing than just the run length encoding this =
simple code is using.

(This code is emitting a 0x90 for 18 zeroes, cnt < 16 on line 52 isn=92t =
the right termination condition.
The examples also include another 0x90 at the end that doesn=92t seem to =
be an actual stop code; none is needed for compression of header-like =
payloads anyway.
But all this can be easily fixed. =20
Also, run codes with more than two consecutive 0xc0s could be further =
compressed with little additional effort.
On the other hand, you don=92t actually make use of the insts array, so =
this could be a simple pointer.)

> With only this code only, I was able to match the manually =
"compressed"
> (optimized) version of ROLL DIO messages, fitting the result into a =
single
> 15.4 frame.

Nice!

>> I completely agree that is is better to shoot for compact protocol
>> encodings in the first place than to fix garrulous encodings after =
the
>> fact by compression.  But we do have a few of the latter that aren=92t
>> going away.
>=20
> I moderately agree with this statement slightly.

:-)

You have to modulate this statement with a suitable value for =93compact=94=
, indeed.

Gr=FC=DFe, Carsten


From sandeep.kumar@philips.com  Fri Jan 17 07:55:11 2014
Return-Path: <sandeep.kumar@philips.com>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD51E1AE12D for <dtls-iot@ietfa.amsl.com>; Fri, 17 Jan 2014 07:55:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 78pzz3DLdC2P for <dtls-iot@ietfa.amsl.com>; Fri, 17 Jan 2014 07:55:10 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id EC9561AE10B for <dtls-iot@ietf.org>; Fri, 17 Jan 2014 07:55:09 -0800 (PST)
Received: from mail18-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE022.bigfish.com (10.243.66.85) with Microsoft SMTP Server id 14.1.225.22; Fri, 17 Jan 2014 15:54:57 +0000
Received: from mail18-co1 (localhost [127.0.0.1])	by mail18-co1-R.bigfish.com (Postfix) with ESMTP id 1A0F02C04F6	for <dtls-iot@ietf.org>; Fri, 17 Jan 2014 15:54:57 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -30
X-BigFish: VPS-30(z579ehz217bI15d6O9371I936eI1be0I542I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2dh109h2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h1155h)
Received: from mail18-co1 (localhost.localdomain [127.0.0.1]) by mail18-co1 (MessageSwitch) id 1389974095311029_9547; Fri, 17 Jan 2014 15:54:55 +0000 (UTC)
Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.232])	by mail18-co1.bigfish.com (Postfix) with ESMTP id 47A424C0046	for <dtls-iot@ietf.org>; Fri, 17 Jan 2014 15:54:55 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 17 Jan 2014 15:54:55 +0000
Received: from 011-DB3MPN1-026.MGDPHG.emi.philips.com ([169.254.6.159]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.03.0158.002; Fri, 17 Jan 2014 15:54:53 +0000
From: "Kumar, Sandeep" <sandeep.kumar@philips.com>
To: "dtls-iot@ietf.org" <dtls-iot@ietf.org>
Thread-Topic: New Version Notification for draft-keoh-dice-multicast-security-03.txt
Thread-Index: AQHPE5u7LZjmYk40Lka3afFcXTRuLJqJERBw
Date: Fri, 17 Jan 2014 15:54:52 +0000
Message-ID: <BE6D13F6A4554947952B39008B0DC0153DB3DF92@011-DB3MPN1-026.MGDPHG.emi.philips.com>
References: <20140117154946.15064.70031.idtracker@ietfa.amsl.com>
In-Reply-To: <20140117154946.15064.70031.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.106]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: philips.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-03.txt
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 15:55:11 -0000

RGVhciBEaWNlIG1lbWJlcnMNCg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgIkRUTFMtYmFzZWQgTXVs
dGljYXN0IFNlY3VyaXR5IiBkcmFmdCBoYXMgYmVlbiB1cGxvYWRlZC4gVGhlIG5ldyB2ZXJzaW9u
IHRha2VzIGludG8gY29uc2lkZXJhdGlvbiB0aGUgY29uc3RydWN0aXZlIGNvbW1lbnRzIHJlY2Vp
dmVkIGR1cmluZyB0aGUgRElDRSBtZWV0aW5nIGluIFZhbmNvdXZlciwgY29tbWVudHMgb24gdGhl
IGxpc3QgYW5kIHByaXZhdGVseS4NCg0KQ29tbWVudHMgb24gdGhlIG5ldyB2ZXJzaW9uIGFyZSB3
ZWxjb21lLg0KDQpLaW5kIHJlZ2FyZHMNClNhbmRlZXANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy
YWZ0c0BpZXRmLm9yZ10NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAxNywgMjAxNCA0OjUwIFBNDQpU
bzogS3VtYXIsIFNhbmRlZXA7IEdhcmNpYSBNb3JjaG9uLCBPc2NhcjsgS3VtYXIsIFNhbmRlZXA7
IFN5ZSBMb29uZyBLZW9oOyBEaWprLCBFc2tvOyBHYXJjaWEgTW9yY2hvbiwgT3NjYXI7IERpamss
IEVza287IFN5ZSBMb29uZyBLZW9oDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g
Zm9yIGRyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDMudHh0DQoNCg0KQSBuZXcg
dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDMudHh0
DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNhbmRlZXAgUy4gS3VtYXIgYW5k
IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQt
a2VvaC1kaWNlLW11bHRpY2FzdC1zZWN1cml0eQ0KUmV2aXNpb246ICAgICAgIDAzDQpUaXRsZTog
ICAgICAgICAgRFRMUy1iYXNlZCBNdWx0aWNhc3QgU2VjdXJpdHkgZm9yIExvdy1Qb3dlciBhbmQg
TG9zc3kgTmV0d29ya3MgKExMTnMpDQpEb2N1bWVudCBkYXRlOiAgMjAxNC0wMS0xNw0KR3JvdXA6
ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDE5DQpVUkw6
ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2Vv
aC1kaWNlLW11bHRpY2FzdC1zZWN1cml0eS0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rZW9oLWRpY2UtbXVsdGljYXN0LXNlY3Vy
aXR5Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtl
b2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDMNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3
LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rZW9oLWRpY2UtbXVsdGljYXN0LXNlY3VyaXR5
LTAzDQoNCkFic3RyYWN0Og0KICAgVGhlIENvQVAgYW5kIDZMb1dQQU4gc3RhbmRhcmRzIGFyZSBm
YXN0IGVtZXJnaW5nIGFzIHRoZSBkZS1mYWN0bw0KICAgcHJvdG9jb2xzIGluIHRoZSBhcmVhIG9m
IHJlc291cmNlLWNvbnN0cmFpbmVkIGRldmljZXMuICBTdWNoIElQLWJhc2VkDQogICBzeXN0ZW1z
IGFyZSBmb3Jlc2VlbiB0byBiZSB1c2VkIGZvciBidWlsZGluZyBhbmQgbGlnaHRpbmcgY29udHJv
bA0KICAgc3lzdGVtcyB3aGVyZSB3aXJlbGVzcyBkZXZpY2VzIGludGVyY29ubmVjdCB3aXRoIGVh
Y2ggb3RoZXIsIGZvcm1pbmcNCiAgIGxvdy1wb3dlciBhbmQgbG9zc3kgbmV0d29ya3MgKExMTnMp
LiAgQm90aCBtdWx0aWNhc3QgYW5kIGl0cyBzZWN1cml0eQ0KICAgYXJlIGtleSBuZWVkcyBpbiB0
aGVzZSBuZXR3b3Jrcy4gIFRoaXMgZHJhZnQgcHJlc2VudHMgYSBtZXRob2QgZm9yDQogICBzZWN1
cmluZyBJUHY2IG11bHRpY2FzdCBjb21tdW5pY2F0aW9uIGluIExMTnMgYmFzZWQgb24gdGhlIERU
TFMgd2hpY2gNCiAgIGlzIGFscmVhZHkgcHJlc2VudCBmb3IgdW5pY2FzdCBpbiB0aGVzZSBDb0FQ
IGRldmljZXMuICBUaGlzIGRyYWZ0DQogICBkZWFscyB3aXRoIHRoZSBhZGFwdGF0aW9uIG9mIHRo
ZSBEVExTIHJlY29yZCBsYXllciB0byBwcm90ZWN0DQogICBtdWx0aWNhc3QgZ3JvdXAgY29tbXVu
aWNhdGlvbiwgYXNzdW1pbmcgdGhhdCBhbGwgZ3JvdXAgbWVtYmVycw0KICAgYWxyZWFkeSBoYXZl
IHRoZSBncm91cCBzZWN1cml0eSBhc3NvY2lhdGlvbiBwYXJhbWV0ZXJzIGluIHRoZWlyDQogICBw
b3NzZXNzaW9uLiAgVGhlIGFkYXB0ZWQgRFRMUyByZWNvcmQgbGF5ZXIgcHJvdmlkZXMgbWVzc2Fn
ZQ0KICAgY29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHkgYW5kIHJlcGxheSBwcm90ZWN0aW9uIHRv
IGdyb3VwIG1lc3NhZ2VzDQogICB1c2luZyB0aGUgZ3JvdXAga2V5aW5nIG1hdGVyaWFsIGJlZm9y
ZSBzZW5kaW5nIHRoZSBtZXNzYWdlIHZpYSBJUHY2DQogICBtdWx0aWNhc3QgdG8gdGhlIGdyb3Vw
Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0
ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u
IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl
Y3JldGFyaWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZv
cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5k
IGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBp
bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBp
bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwg
Zm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2Fn
ZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUg
bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkg
cmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNz
YWdlLg0K


From mglt.ietf@gmail.com  Fri Jan 31 06:48:19 2014
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE8E1A0064; Fri, 31 Jan 2014 06:48:19 -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 Y0v27GMR_laG; Fri, 31 Jan 2014 06:48:17 -0800 (PST)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id AAC9B1A020C; Fri, 31 Jan 2014 06:48:16 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id l18so9102324wgh.5 for <multiple recipients>; Fri, 31 Jan 2014 06:48:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=e5av1DSGZsFTk/UHfhKFrgPp27dwhqpN7flBjKw4LIs=; b=QzSkaI15ZZY6yYJ1jVyM9KXLhUV2V6V92SHHVhn/ltw8I9xIXhdg5LNL0YS4189TGO BdAz06f+NK/B1/rm/NCYTWX4SP0sHd6Z5U8i6tpJvDYwlcMRAFO0rF/R5d8Csjfns0Bv fjKWBydcI9rzUPQY46cCxnobJWnhGR4GuEb2MG/KqkDr8HVYLJ7TLmyOEiga6Dqh6ldK ttgea4XAesJrZu/BjusovxxHP5nSrtQC6yNxZzKjEoWHcsDjC7WLgApXuPK8dRT/yzvw ARj1IdJ/P4TfNHCUAOtJczcK/tpDgiEegecKnmSPYZc1yB/Cqyzgbdot7HCS66GtKaGq bJsQ==
MIME-Version: 1.0
X-Received: by 10.180.94.67 with SMTP id da3mr14287274wib.38.1391179692606; Fri, 31 Jan 2014 06:48:12 -0800 (PST)
Received: by 10.194.171.129 with HTTP; Fri, 31 Jan 2014 06:48:12 -0800 (PST)
Date: Fri, 31 Jan 2014 15:48:12 +0100
Message-ID: <CADZyTk=GRC4kN5mXobgzeZJ+k44dxZHLaW49z8dFkjt0N=C5aw@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>, dtls-iot@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 14:48:19 -0000

Hi,

Please find the two drafts we have just posted. They are about
IPsec/ESP minimal implementation and Diet-ESP designed for IoT.

Comment are welcome!

Best Regards,
Daniel


Name:        draft-mglt-dice-diet-esp
Revision:    00
Title:        Diet-ESP: a flexible and compressed format for IPsec/ESP
Document date:    2014-01-31
Group:        Individual Submission
Pages:        21
URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt
Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/
Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00


Abstract:
   IPsec/ESP has been designed to secure IP packets exchanged between
   two nodes.  IPsec implements security at the IP layer which makes
   security transparent to the applications, as opposed to TLS or DTLS
   that requires application to implement TLS/DTLS.  As a result, IPsec
   enable to define the security rules in a similar way one establishes
   firewall rules.

   One of the IPsec's drawbacks is that implementing security on a per
   packet basis adds overhead to each IP packet.  Considering IoT
   devices, the data transmitted over an IP packet is expected to be
   rather small, and the cost of sending extra bytes is so high that
   IPsec/ESP can hardly be used for IoT as it is currently defined in
   RFC 4303.

   This document defines Diet-ESP, a protocol that compress and reduce
   the ESP overhead of IPsec/ESP so that it can fit security and energy
   efficient IoT requirements.  Diet-ESP use already existing mechanism
   like IKEv2 to negotiate the compression format.  Furthermore a lot of
   information, already existing for an IPsec Security Association, are
   reused to offer light negotiation in addition to maximum compression.


Name:        draft-mglt-lwig-minimal-esp
Revision:    00
Title:        Minimal ESP
Document date:    2014-01-31
Group:        Individual Submission
Pages:        6
URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt
Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/
Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00


Abstract:
   This document describes a minimal version of the IP Encapsulation
   Security Payload (ESP) described in RFC 4303 which is part of the
   IPsec suite.

   ESP is used to provide confidentiality, data origin authentication,
   connectionless integrity, an anti-replay service (a form of partial
   sequence integrity), and limited traffic flow confidentiality.

   This document does not update or modify RFC 4303, but provides a
   compact description of the minimal version of the protocol.  If this
   document and RFC 4303 conflicts then RFC 4303 is the authoritative
   description.


-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

From hannes.tschofenig@gmx.net  Fri Jan 31 12:12:56 2014
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5A31A0448 for <dtls-iot@ietfa.amsl.com>; Fri, 31 Jan 2014 12:12:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.665
X-Spam-Level: 
X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.535, 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 YFvdoFhf408I for <dtls-iot@ietfa.amsl.com>; Fri, 31 Jan 2014 12:12:54 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 269541A0464 for <dtls-iot@ietf.org>; Fri, 31 Jan 2014 12:12:54 -0800 (PST)
Received: from [192.168.10.207] ([212.95.7.40]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MRXVc-1VgqHx00IC-00ScJp for <dtls-iot@ietf.org>; Fri, 31 Jan 2014 21:12:49 +0100
Message-ID: <52EC03BC.60609@gmx.net>
Date: Fri, 31 Jan 2014 20:12:44 +0000
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Daniel Migault <mglt.ietf@gmail.com>
References: <CADZyTk=GRC4kN5mXobgzeZJ+k44dxZHLaW49z8dFkjt0N=C5aw@mail.gmail.com>
In-Reply-To: <CADZyTk=GRC4kN5mXobgzeZJ+k44dxZHLaW49z8dFkjt0N=C5aw@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oFgOsocm1DXnv3AlXv3DckEOtQpgGj3VE"
X-Provags-ID: V03:K0:baQN3WBgRu9k0gTmJZ9LZQQ6K8aue+mYFFjw5U2ZTbBp9s/U9lB sOabHqSA3u3IE8YnWbCL/a5XxkMXxwwPnjq2LNUiqg6MMuB4vX3BY79dLaeDjAZCadFOu83 sexKZQkqbYu49q5ZFm7D0oWF/flSGTyACeE2zFSESgVDc0QNB0hIgTuutGoM8m8urhn2t7K ik/kR3G/yR+j+xu5P9NvQ==
Cc: dtls-iot@ietf.org
Subject: Re: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 20:12:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--oFgOsocm1DXnv3AlXv3DckEOtQpgGj3VE
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Daniel,

the charter of the DICE working group considers IPsec/IKEv2 outside the
scope. The charter also requires the work to be a profile rather than a
new design. A profile is just a subset of the functionality of the
existing protocol that would still interoperate with the full version.

On the content: Do you plan to use the work within your company / in
products? I have not ran into someone who was planning to use IPsec in
the IoT context but I am happy to learn about new deployments.

Ciao
Hannes


On 01/31/2014 02:48 PM, Daniel Migault wrote:
> Hi,
>=20
> Please find the two drafts we have just posted. They are about
> IPsec/ESP minimal implementation and Diet-ESP designed for IoT.
>=20
> Comment are welcome!
>=20
> Best Regards,
> Daniel
>=20
>=20
> Name:        draft-mglt-dice-diet-esp
> Revision:    00
> Title:        Diet-ESP: a flexible and compressed format for IPsec/ESP
> Document date:    2014-01-31
> Group:        Individual Submission
> Pages:        21
> URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt=

> Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/
> Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00
>=20
>=20
> Abstract:
>    IPsec/ESP has been designed to secure IP packets exchanged between
>    two nodes.  IPsec implements security at the IP layer which makes
>    security transparent to the applications, as opposed to TLS or DTLS
>    that requires application to implement TLS/DTLS.  As a result, IPsec=

>    enable to define the security rules in a similar way one establishes=

>    firewall rules.
>=20
>    One of the IPsec's drawbacks is that implementing security on a per
>    packet basis adds overhead to each IP packet.  Considering IoT
>    devices, the data transmitted over an IP packet is expected to be
>    rather small, and the cost of sending extra bytes is so high that
>    IPsec/ESP can hardly be used for IoT as it is currently defined in
>    RFC 4303.
>=20
>    This document defines Diet-ESP, a protocol that compress and reduce
>    the ESP overhead of IPsec/ESP so that it can fit security and energy=

>    efficient IoT requirements.  Diet-ESP use already existing mechanism=

>    like IKEv2 to negotiate the compression format.  Furthermore a lot o=
f
>    information, already existing for an IPsec Security Association, are=

>    reused to offer light negotiation in addition to maximum compression=
=2E
>=20
>=20
> Name:        draft-mglt-lwig-minimal-esp
> Revision:    00
> Title:        Minimal ESP
> Document date:    2014-01-31
> Group:        Individual Submission
> Pages:        6
> URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.=
txt
> Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/
> Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00
>=20
>=20
> Abstract:
>    This document describes a minimal version of the IP Encapsulation
>    Security Payload (ESP) described in RFC 4303 which is part of the
>    IPsec suite.
>=20
>    ESP is used to provide confidentiality, data origin authentication,
>    connectionless integrity, an anti-replay service (a form of partial
>    sequence integrity), and limited traffic flow confidentiality.
>=20
>    This document does not update or modify RFC 4303, but provides a
>    compact description of the minimal version of the protocol.  If this=

>    document and RFC 4303 conflicts then RFC 4303 is the authoritative
>    description.
>=20
>=20


--oFgOsocm1DXnv3AlXv3DckEOtQpgGj3VE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJS7AO8AAoJEGhJURNOOiAtSYYIAJxU8oVP8S0RJ9QCAlK1Kxdo
dPYAQWHCVTLdVfdotUduy6apSJr+sxyeS2hOKRt5R0Zmu7mnN0+h7wVX6J+DLeYc
tbMNs8meywL4DTu3vs/m7x6Vaua0u6GDkgc3uuCGV+mHUbn1RqLVYQ5JL4QjNX1o
ub17Nf7q0+Igj19t6OHrP3rHg7uCvxsSLW6P199Iah23RxBjfF1fxqX+VWCP/Geq
EHHBh6eCyjh+NCqoFZXtBzngoxu6XCY53YR/GtSqiKhCDnOUvQBpsi5PJ7yuv57u
LUFzArH8h2dmkkdPYaYbcqeiI/vAr+z6RjNajrWZXa2iTtKguxO1mDtH909+KO8=
=GHY8
-----END PGP SIGNATURE-----

--oFgOsocm1DXnv3AlXv3DckEOtQpgGj3VE--