Re: [lisp] [5gangip] Bandwidth savings with LISP
Ca By <cb.list6@gmail.com> Mon, 04 July 2016 14:14 UTC
Return-Path: <cb.list6@gmail.com>
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 4C67112D0FB; Mon, 4 Jul 2016 07:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 zKOb88-6zEfO; Mon, 4 Jul 2016 07:14:48 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 9CE0512D0D9; Mon, 4 Jul 2016 07:14:47 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id r201so117419814wme.1; Mon, 04 Jul 2016 07:14:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1/UolYFnGtLbugUVM0ApFmCDlNYj7ExoNflCcBTPMvU=; b=wstaMtSg6dAqWPkLiSv2DXRed8I0sb8T/sCH5PsQSLLp3uS4Sz1h4dahLRgsCuKY2M 1N77+gkbQXjiP6+POEdoG47RylLqLU8BcqIUecmUofzZn/OIxc7E7CNlhzKPRck0Ewyz iXM0laSTS69y9YeFrx9cJbXuscrFD5fYfaQuAwA4XUSHJbyl2EJXpze8a4I3zJfXeG/w HcXBjC60eJOTG7JswabjsfVYqrILt9cgjLLibXKej/ig9Qh69HWO+KCfFDIinFsYmAim vVZu40pbpIVvqLW/V1AklF66/ndoROllBlwGHue9JQ7GVqdIpUah5jZYmhbg/j0E6I41 g1Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1/UolYFnGtLbugUVM0ApFmCDlNYj7ExoNflCcBTPMvU=; b=gIQQum8BaK7stMfvuCKdlvq7E5o0mkFTHIkGhNgsBqR7QIsjs4+lvpGbHKgNPp//M4 9AwA78PSpuIr9mx+XQPQtbSGzhP1RbqRaYaMT9VSnH9aZExrvKGqIkgtVRJJgA/MrEDY Eeu/F8PzCRLj710dh6bgIvcmSyx5hdlQOlVMRscRLjXaGLQtCjE2UUaHv9RjY3QyRjEF NkUiAayQawF/Yku+C6qLfKHe//Ca4j3WIpPUO6eAeqYZRnHkyAezI88V3XmEBpk1qrQg v+3qVm1YjdlZF+VwFFtfIF5uaBRw67MFblta6LI1zsIhB3aV6aeaPO+VUYxcepsGp5dP kp9g==
X-Gm-Message-State: ALyK8tIhLLQbRwgQIiyPrLgCYOMCMT2Yviu9/UuVStrxJgqW3dXvgCwAOuoAVfmiUsysjosWzrGaBEHeaEPyKA==
MIME-Version: 1.0
X-Received: by 10.194.139.50 with SMTP id qv18mr6383160wjb.47.1467641685871; Mon, 04 Jul 2016 07:14:45 -0700 (PDT)
Received: by 10.28.164.194 with HTTP; Mon, 4 Jul 2016 07:14:45 -0700 (PDT)
In-Reply-To: <6C1441C1-90C3-457B-8146-4869C9FE5929@gmail.com>
References: <007601d1cd2f$3a8cad70$afa60850$@unizar.es> <576C060C.2070907@cisco.com> <00ab01d1d38d$17365060$45a2f120$@unizar.es> <6C1441C1-90C3-457B-8146-4869C9FE5929@gmail.com>
Date: Mon, 04 Jul 2016 07:14:45 -0700
Message-ID: <CAD6AjGRokOVdB7Z4TpxmCqi_9nOajT0e7b=y3VcsQrqVy1KJTg@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Content-Type: multipart/alternative; boundary="f46d04095bed581ae80536cff540"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/CQ8eCwvsUNFUWbkxPc8F7ARrRCc>
Cc: "5gangip@ietf.org" <5gangip@ietf.org>, José Ruiz Mas <jruiz@unizar.es>, LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] [5gangip] 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: Mon, 04 Jul 2016 14:14:51 -0000
On Friday, July 1, 2016, Dino Farinacci <farinacci@gmail.com> wrote: > 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 > > I dont think this will fly. LISP is a lot of work and Super Framing / packing is a edge case benefit, especially when layering on top of all the other muck A real benefit that would justify heavy lifting is replacing the 5G core with an alternative mobility system such as LISP or ILNP. http://telecoms.com/wp-content/blogs.dir/1/files/2016/06/5G-architecture-options.pdf You can see that new core is a green field opportunity to replace the mobility system, which is very high value area. CB > > On Jul 1, 2016, at 4:38 AM, Jose Saldana <jsaldana@unizar.es > <javascript:;>> 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 <javascript:;>] > >> Enviado el: jueves, 23 de junio de 2016 17:54 > >> Para: Jose Saldana <jsaldana@unizar.es <javascript:;>>; lisp@ietf.org > <javascript:;> > >> CC: 'José Ruiz Mas' <jruiz@unizar.es <javascript:;>> > >> 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 <javascript:;>] En nombre de > Jose Saldana > >>>> Enviado el: miércoles, 04 de mayo de 2016 18:41 > >>>> Para: lisp@ietf.org <javascript:;> > >>>> CC: 'Jose Ruiz Mas' <jruiz@unizar.es <javascript:;>> > >>>> 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 <javascript:;> [mailto: > internet-drafts@ietf.org <javascript:;>] > >>>>> Enviado > >>>>> el: miércoles, 04 de mayo de 2016 18:20 > >>>>> Para: Jose Ruiz Mas <jruiz@unizar.es <javascript:;>>; Jose Saldana > >>>>> <jsaldana@unizar.es <javascript:;>>; Julian Fernandez Navajas < > navajas@unizar.es <javascript:;>> > >>>>> 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 <javascript:;> > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>> > >>> > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org <javascript:;> > >>> https://www.ietf.org/mailman/listinfo/lisp > >>> > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org <javascript:;> > > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org <javascript:;> > https://www.ietf.org/mailman/listinfo/5gangip >
- Re: [lisp] [5gangip] Bandwidth savings with LISP Rex Buddenberg
- Re: [lisp] [5gangip] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [lisp] [5gangip] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [lisp] [5gangip] Bandwidth savings with LISP Dino Farinacci
- Re: [lisp] [5gangip] Bandwidth savings with LISP AshwoodsmithPeter
- Re: [lisp] [5gangip] Bandwidth savings with LISP Dino Farinacci
- Re: [lisp] [5gangip] Bandwidth savings with LISP Behcet Sarikaya
- Re: [lisp] [5gangip] Bandwidth savings with LISP Jose Saldana
- Re: [lisp] [5gangip] Bandwidth savings with LISP Dino Farinacci
- Re: [lisp] [5gangip] Bandwidth savings with LISP Dino Farinacci
- Re: [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [lisp] [5gangip] Bandwidth savings with LISP Ca By
- Re: [lisp] [5gangip] Bandwidth savings with LISP AshwoodsmithPeter
- Re: [lisp] [5gangip] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [lisp] Bandwidth savings with LISP julian
- Re: [lisp] Bandwidth savings with LISP Anton Smirnov
- Re: [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [lisp] Bandwidth savings with LISP Anton Smirnov
- [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [lisp] [5gangip] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [lisp] [5gangip] Bandwidth savings with LISP Rex Buddenberg
- Re: [lisp] [5gangip] Bandwidth savings with LISP Jose Saldana