Re: [lisp] Bandwidth savings with LISP

julian <navajas@unizar.es> Fri, 01 July 2016 14:48 UTC

Return-Path: <navajas@unizar.es>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617D112D663 for <lisp@ietfa.amsl.com>; Fri, 1 Jul 2016 07:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level:
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] 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 iN_voxNwGZF1 for <lisp@ietfa.amsl.com>; Fri, 1 Jul 2016 07:48:36 -0700 (PDT)
Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB86F12D12E for <lisp@ietf.org>; Fri, 1 Jul 2016 07:48:31 -0700 (PDT)
Received: from [155.210.156.37] (tele3.cps.unizar.es [155.210.156.37]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id u61EmMgS007452 for <lisp@ietf.org>; Fri, 1 Jul 2016 16:48:23 +0200
To: lisp@ietf.org
References: <007601d1cd2f$3a8cad70$afa60850$@unizar.es> <576C060C.2070907@cisco.com> <00ab01d1d38d$17365060$45a2f120$@unizar.es> <57766346.30707@cisco.com>
From: julian <navajas@unizar.es>
Message-ID: <44270555-9f4e-1112-e060-c1ade55d125b@unizar.es>
Date: Fri, 01 Jul 2016 16:48:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <57766346.30707@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/M8CmRKALDjRwRtzzUz6U8jxct5I>
Subject: Re: [lisp] Bandwidth savings with LISP
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2016 14:48:38 -0000

Hi Anton and José,

Regarding how the ITR and ETR will be able to encapsulate and to 
decapsulate the packets, one option is that this information could be at 
the level of application of the packets. Therefore, it would be 
transparent to LISP.

A solution to avoid using marked packets is to use a different port to 
4341, i.e. 4343. All the data in this port will be muliplexed.

By last, the latency would be bounded at the mux configuration, in order 
to maintain quality of service without requiring aditional research.

Julián


El 01/07/2016 a las 14:34, Anton Smirnov escribió:
>    Hi Jose,
>    marking packet as compressed is one thing - necessary but not 
> sufficient. Backward compatibility includes considerations like how 
> ITR would decide which encapsulation to use while sending out packet 
> for a particular remote EID (i.e. that ETR will be able to decapsulate 
> it).
>    Also, you should investigate and document the practical use case, 
> i.e. what is the likelihood of being able to compress packets in 
> real-world traffic patterns, what it means for latencies (protocols 
> using smaller packets tend to be more sensitive to delay and jitter) 
> and so on.
>    Without those bits the idea is a bit detached.
>
> Anton
>
>
> On 07/01/2016 01:38 PM, Jose Saldana wrote:
>> Hi again, Anton.
>>
>> I have just uploaded a new presentation including more ideas and also 
>> a section about backward compatibility:
>>
>> http://es.slideshare.net/josemariasaldana/header-compression-and-multiplexing-in-lisp 
>>
>>
>> BR and thanks,
>>
>> Jose
>>
>>> -----Mensaje original-----
>>> De: Anton Smirnov [mailto:asmirnov@cisco.com]
>>> Enviado el: jueves, 23 de junio de 2016 17:54
>>> Para: Jose Saldana <jsaldana@unizar.es>; lisp@ietf.org
>>> CC: 'José Ruiz Mas' <jruiz@unizar.es>
>>> Asunto: Re: [lisp] Bandwidth savings with LISP
>>>
>>>      Hi Jose,
>>>      there is a theoretical aspect of the work (it's curious) and 
>>> then there is a practical
>>> one. For the latter one - section "Backward compatibility" is 
>>> conspicuously missing
>>> from the document. On the first glance, it looks like backward 
>>> compatibility of the
>>> solution was not investigated. Is this correct?
>>>
>>> Anton
>>>
>>>
>>> On 06/23/2016 11:11 AM, Jose Saldana wrote:
>>>> Hi all,
>>>>
>>>> As you may know, we recently submitted a draft
>>> (https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/) 
>>> with a proposal
>>> allowing bandwidth and pps reductions.
>>>>
>>>> The idea is to send together a number of small packets, which are 
>>>> in the buffer of
>>> an ITR and have the same ETR as destination, into a single packet. 
>>> Therefore, they
>>> will share a single LISP header. And this can be combined with ROHC 
>>> (header
>>> compression).
>>>>
>>>> We have a running implementation, based on LISPMob
>>>> (https://github.com/Simplemux/lispmob-with-simplemux), which we have
>>>> used to run some tests
>>>>
>>>> This is a summary of the results.
>>>>
>>>> - When small packets (100 bytes) are sent, up to 63% of throughput 
>>>> increase can
>>> be observed (in our example, we pass from 550kbps to 910kbps).
>>>>
>>>> - In the case of securing the LISP tunnel with IPSec, the increase 
>>>> can be 935
>>> (from 470kbps to 870kbps).
>>>>
>>>> You can find more detailed information in this presentation:
>>>> http://es.slideshare.net/josemariasaldana/header-compression-and-multi
>>>> plexing-in-lisp
>>>>
>>>> Your feedback will be highly appreciated.
>>>>
>>>> Best regards,
>>>>
>>>> The authors
>>>>
>>>>> -----Mensaje original-----
>>>>> De: lisp [mailto:lisp-bounces@ietf.org] En nombre de Jose Saldana
>>>>> Enviado el: miércoles, 04 de mayo de 2016 18:41
>>>>> Para: lisp@ietf.org
>>>>> CC: 'Jose Ruiz Mas' <jruiz@unizar.es>
>>>>> Asunto: [lisp] New draft posted:
>>>>> draft-saldana-lisp-compress-mux-00.txt
>>>>>
>>>>> Hi all,
>>>>>
>>>>> We have just posted this draft
>>>>> https://datatracker.ietf.org/doc/draft-saldana-lisp-
>>>>> compress-mux/.
>>>>>
>>>>>                 Header compression and multiplexing in LISP
>>>>>                      draft-saldana-lisp-compress-mux-00
>>>>>
>>>>> Abstract
>>>>>
>>>>>      When small payloads are transmitted through a packet-switched
>>>>>      network, the resulting overhead may result significant.  This is
>>>>>      stressed in the case of LISP, where a number of headers are 
>>>>> prepended
>>>>>      to a packet, as new headers have to be added to each packet.
>>>>>
>>>>>      This document proposes to send together a number of small 
>>>>> packets,
>>>>>      which are in the buffer of a ITR, having the same ETR as 
>>>>> destination,
>>>>>      into a single packet.  Therefore, they will share a single LISP
>>>>>      header, and therefore bandwidth savings can be obtained, and a
>>>>>      reduction in the overall number of packets sent to the 
>>>>> network can be
>>>>>      achieved.
>>>>>
>>>>> A running implementation can be found here:
>>>>> https://github.com/Simplemux/lispmob-with-simplemux. I has been built
>>>>> as a fork of lispmob.
>>>>>
>>>>> The idea is very similar to what was published in this paper:
>>>>> http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_in_proc.pd
>>>>> f
>>>>>
>>>>> Your feedback about the draft will be appreciated.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Jose Saldana
>>>>> Julián Fernández Navajas
>>>>> José Ruiz Mas
>>>>>
>>>>>> -----Mensaje original-----
>>>>>> De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>>>> Enviado
>>>>>> el: miércoles, 04 de mayo de 2016 18:20
>>>>>> Para: Jose Ruiz Mas <jruiz@unizar.es>; Jose Saldana
>>>>>> <jsaldana@unizar.es>; Julian Fernandez Navajas <navajas@unizar.es>
>>>>>> Asunto: New Version Notification for
>>>>>> draft-saldana-lisp-compress-mux-00.txt
>>>>>>
>>>>>>
>>>>>> A new version of I-D, draft-saldana-lisp-compress-mux-00.txt
>>>>>> has been successfully submitted by Jose Saldana and posted to the
>>>>>> IETF repository.
>>>>>>
>>>>>> Name:        draft-saldana-lisp-compress-mux
>>>>>> Revision:    00
>>>>>> Title:        Header compression and multiplexing in LISP
>>>>>> Document date:    2016-05-04
>>>>>> Group:        Individual Submission
>>>>>> Pages:        8
>>>>>> URL:
>>>>>> https://www.ietf.org/internet-drafts/draft-saldana-lisp-compress-mux
>>>>>> -
>>>>>> 00.txt
>>>>>> Status:
>>>>>> https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/
>>>>>> Htmlized:
>>>>>> https://tools.ietf.org/html/draft-saldana-lisp-compress-mux-00
>>>>>>
>>>>>>
>>>>>> Abstract:
>>>>>>      When small payloads are transmitted through a packet-switched
>>>>>>      network, the resulting overhead may result significant.  
>>>>>> This is
>>>>>>      stressed in the case of LISP, where a number of headers are 
>>>>>> prepended
>>>>>>      to a packet, as new headers have to be added to each packet.
>>>>>>
>>>>>>      This document proposes to send together a number of small 
>>>>>> packets,
>>>>>>      which are in the buffer of a ITR, having the same ETR as 
>>>>>> destination,
>>>>>>      into a single packet.  Therefore, they will share a single LISP
>>>>>>      header, and therefore bandwidth savings can be obtained, and a
>>>>>>      reduction in the overall number of packets sent to the 
>>>>>> network can be
>>>>>>      achieved.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>> submission until the htmlized version and diff are available at
>>>>>> tools.ietf.org.
>>>>>>
>>>>>> The IETF Secretariat
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> lisp mailing list
>>>>> lisp@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>
>>>>
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>
>>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>
>