Re: [5gangip] [lisp] Bandwidth savings with LISP

Dino Farinacci <farinacci@gmail.com> Fri, 01 July 2016 17:05 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288C412D772; Fri, 1 Jul 2016 10:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gnpjOoHPYra2; Fri, 1 Jul 2016 10:05:07 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 CFD2F12D764; Fri, 1 Jul 2016 10:05:07 -0700 (PDT)
Received: by mail-pa0-x22f.google.com with SMTP id bz2so40345982pad.1; Fri, 01 Jul 2016 10:05:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NnDYTsGH6xzoK1CYhXQDN0cHrzI3zpUij2/tT1BYh8w=; b=flOfUuGRVnZuQQSXkpp4RZ1Pzsj+UyQG9gtJs/O9DmFuzx4ZHYRam1rPtYI7fE1pq8 BTeb4wy9zNzY6qRANF964bjonLvo0KJJLjW+mTSBG6VB3hOfjkpUjF8RnuGF/+C+zuOk LkrA3+h9xp8kuxJ8cXigqCw7f9/VPwQFYprzePAoyJ0FbfkzrasH2KE9T/Qdv6Q/yJP0 7k2H3RrKIf570i0rQNaO5Z7BxRSlw+ho22p9Ovj4WoL5Z53x3GDEdl9gjUWU8mG2D66V DpyzCrqUi0oyZkNbHZaDIKjup0FY6R4Ll98xdv7lC0wy4AQBrHk3HvDvenepZRhfhIxd JHOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NnDYTsGH6xzoK1CYhXQDN0cHrzI3zpUij2/tT1BYh8w=; b=Kv4GAHsm+1ll+TlvkxLkMVLP8cqiCsj52Pv+gycqYuKj6TWPFB/lUeHKFFMCB23hXW 4z3ZTELPG9GFNPFVrJva3jUM1JJXRgsjMffB8K0EaCjOXs+cumbVdJeu+T/AVu/3FHpj gfvKzXyQBzAZPUZYbXtsr+7qLL1ileOyK6A7EoTJiZfQ/wndXOoV9hktmXO8s4GrXF9V JSjnX3uv/pyRB1xw62XpZM0NUT+tkNNZC5pO3kU7b35Zp7YKm29sGd3k/HkgjmO2pt3d HMPaWsWN5HwHwJC8QCqB1gd6mMMYcedWtYhjgPBi/zmMMfAuGP/UX6JLOcO+E14LzlNr x3Fg==
X-Gm-Message-State: ALyK8tIKtP9MdN4QkZ8p4+NVpE8kAPZPScj+qEArca4n+88jvRbczclTOAxpKs3UBchI0A==
X-Received: by 10.66.15.232 with SMTP id a8mr33961283pad.129.1467392707292; Fri, 01 Jul 2016 10:05:07 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id i3sm6981245pfk.30.2016.07.01.10.05.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 10:05:06 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <00ab01d1d38d$17365060$45a2f120$@unizar.es>
Date: Fri, 01 Jul 2016 10:05:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C1441C1-90C3-457B-8146-4869C9FE5929@gmail.com>
References: <007601d1cd2f$3a8cad70$afa60850$@unizar.es> <576C060C.2070907@cisco.com> <00ab01d1d38d$17365060$45a2f120$@unizar.es>
To: Jose Saldana <jsaldana@unizar.es>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/uXm7jp-3JwbYmLCkN_e4Oh-X_8I>
Cc: 5gangip@ietf.org, José Ruiz Mas <jruiz@unizar.es>, LISP mailing list list <lisp@ietf.org>, Anton Smirnov <asmirnov@cisco.com>
Subject: Re: [5gangip] [lisp] Bandwidth savings with LISP
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2016 17:05:10 -0000

So I have been thinking about a compelling use-case for LISP header-compression and the super-framing feature (sorry for using my own term).

I have been told that the Radio Access Network (RAN) tends to be sensitive to overlay solutions due to large headers. I have also heard that there seems to be queuing behavior for the base-stations that send to UEs (i.e. phones). The fact that queuing is happening while waiting for a handoffs to occur can be a good opportunity to pack IP packets into super-frames to send over the RAN.

Using this solution means the eNodeB (base-station) and the UE (phone) would have to run LISP. I would like to hear comments from the WG. I have copied 5gangip to see if they have opinions.

Dino

> On Jul 1, 2016, at 4:38 AM, Jose Saldana <jsaldana@unizar.es> 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