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
- [IPsec] IPsec/Diet-ESP for IoT and Minimal ESP Daniel Migault
- Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and… Daniel Migault
- Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and… Daniel Migault
- Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and… Yaron Sheffer
- Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and… Valery Smyslov
- Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and… Daniel Migault
- Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and… Valery Smyslov
- Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and… Tobias Guggemos