Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP

Tobias Guggemos <tobias.guggemos@stud.ifi.lmu.de> Fri, 28 February 2014 15:00 UTC

Return-Path: <tobias.guggemos@stud.ifi.lmu.de>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8A01A01E8; Fri, 28 Feb 2014 07:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 fH-gUPE1iVqD; Fri, 28 Feb 2014 07:00:27 -0800 (PST)
Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) by ietfa.amsl.com (Postfix) with ESMTP id 09BFF1A07C0; Fri, 28 Feb 2014 07:00:27 -0800 (PST)
Received: from webmail2.cip.ifi.lmu.de (mailserv1.ifi.lmu.de [IPv6:2001:4ca0:4000:0:141:84:220:222]) by acheron.ifi.lmu.de (Postfix) with ESMTP id 9E9F094A142; Fri, 28 Feb 2014 16:00:24 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Fri, 28 Feb 2014 16:00:24 +0100
From: Tobias Guggemos <tobias.guggemos@stud.ifi.lmu.de>
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <AE7FAD7209504483B5444AF43BD9BF23@buildpc>
References: <CADZyTk=k3=-BN=8ma=beMh9b0skswW-SvmbP9Ae2AOQwbV0k-Q@mail.gmail.com><530393EA.5020008@gmail.com><F1954BB774EA4C7DAA729D2623D8F364@buildpc> <CADZyTk=TQxr3eToEqbUKr3e3pa4iMKz2hd9ZA=s-bXfb_tnPzg@mail.gmail.com> <AE7FAD7209504483B5444AF43BD9BF23@buildpc>
Message-ID: <4e008ff196be9869dd80785909687adf@imap.cip.ifi.lmu.de>
X-Sender: tobias.guggemos@stud.ifi.lmu.de
User-Agent: Roundcube Webmail/1.0-beta
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/foDM8YrxZ2uYijXavluyasgVj-0
Cc: ipsec@ietf.org, lwip@ietf.org, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Sye Loong Keoh <SyeLoong.Keoh@glasgow.ac.uk>, Daniel Migault <mglt.ietf@gmail.com>
Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2014 15:00:30 -0000

Hello Valery

Yes we considered ROHC and also 6LoWPAN, because both include 
possibilities for compression ESP.
First, it's definitely an option and remains an option even if Diet-ESP 
is going to be used.
We are thinking about Diet-ESP because:
- If I'm right ROHC needs at least one uncompressed packet to be send, 
which may be expensive.
- As we want to use IPsec/ESP we have all necessary information in the 
SAD/SPD to restore the information of IP/UDP/(partly TCP). The idea is 
to use them instead of adding ROHC compressors between the different 
layers which 1) adds ROM space (which may be limited) and 2) storage for 
an information which is already there.
- In case of Diet-ESP it is really simple to restore the payload headers 
and it costs only two bits to send once in the session. This is why we 
decided to add this as an option.

BR
Tobias

Am 28.02.2014 07:34, schrieb Valery Smyslov:
> Hi Daniel,
> 
>> However, the ratio computing vs communication in IoT is quite
>> impressive and there is a high interest in compressing frames before
>> transmitting them.
>>    - Computing ranges from 0.5nJ per instruction for extremely
>> energy-efficient microcontrollers (such as CoolRisc or MSP430) to 200
>> nJ per instruction for high-performance microprocessors (such as
>> ARM9).
>>    - Communication: from 100nJ to 1uJ per bit transmitted or
>> received, depending on modulation complexity and transmission power
>> (we only consider "low-power" radios, with transmit powers lower than
>> about 10mW).
>> 
>> Roughly speaking, this means that, for the energy cost of exchanging 1
>> bit, our system can alternatively compute 10-100 instructions.
> 
> Yes, it's impressive. Did you consider using ROHC (RObust Header 
> Compression)?
> It will allow you to significantly decrease size of TCP/UDP/IP headers.
> 
> Regards,
> Valery Smyslov.
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec