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
- Re: [5gangip] [lisp] Bandwidth savings with LISP Rex Buddenberg
- Re: [5gangip] [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [5gangip] [lisp] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [5gangip] [lisp] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [5gangip] [lisp] Bandwidth savings with LISP Rex Buddenberg
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP AshwoodsmithPeter
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP Behcet Sarikaya
- Re: [5gangip] [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [5gangip] [lisp] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP Ca By
- Re: [5gangip] [lisp] Bandwidth savings with LISP AshwoodsmithPeter
- Re: [5gangip] [lisp] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [5gangip] [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci