On Wed, Jul 6, 2016 at 1:06 AM, PEDRO ANDRES ARANDA GUTIERREZ <[email protected]> wrote: > Answers inline, marked with [PA] > > It’s my (-) .02 cents > Best, > --- > Dr. Pedro A. Aranda Gutiérrez > > > > Technology Exploration - > Network Innovation & Virtualisation > email: pedroa d0t aranda At telefonica d0t com > Telefónica, Investigación y Desarrollo > > C/ Zurbarán,12 > 28010 Madrid, Spain > > > > Fragen sind nicht da, um beantwortet zu werden. > Fragen sind da, um gestellt zu werden. > > Georg Kreisler > > -----Mensaje original----- > De: 5gangip <[email protected]> en nombre de Dino Farinacci > <[email protected]> > Fecha: martes, 5 de julio de 2016, 20:00 > Para: Ca By <[email protected]> > CC: "[email protected]" <[email protected]>, José Ruiz Mas <[email protected]>, > Anton Smirnov <[email protected]>, LISP mailing list list <[email protected]>, > Jose Saldana <[email protected]> > Asunto: Re: [5gangip] [lisp] Bandwidth savings with LISP > >> On Friday, July 1, 2016, Dino Farinacci <[email protected]> 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. > > I tend to agree. > > [PA] Hey folks, 5G is going for slices for many good reasons. One of these is > to avoid stacking headers… especially in the RAN. > >> 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 > > Let’s not conflate running LISP and super-framing. I think running LISP (but > not on the UE) is really an easy deployable solution.
I think we should discuss this further. Why can't we run LISP on UE? Does it have to run on the host for proper LISP operation? > That is a separate topic for discussion. This thread was focusing on > super-framing. > > [PA] No objection to use all these wonderful things you propose in the CORE, > but there is a lot of processing before that and there’s where my part kicks > in, right? ;-) > >> A real benefit that would justify heavy lifting is replacing the 5G core >> with an alternative mobility system such as LISP or ILNP. > > Right, we will have several presentations at the 5gangip BOF discussing this. > > [PA] Hey folks, what does 5G core actually mean? For me it will be the core > of the 5G network, which is currently TBD. So instead of thinking about > replacing something that does not exist, why don’t we argue that this core > part of the future 5G network would benefit for supporting LISP? ;-) > Core network is 3GPP terminology, it comes after RAN and it is the part that connects to the Internet. So the term core network could be confusing to IETF folks. Yes, I think that we should discuss the prospects of future 5G core network would benefit from supporting LISP, but why and how? Regards, Behcet >> 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. > > Yes, I and many are aware of the opportunity. > > [PA] Me too, just trying to put things into (yet another) perspective (with > no claim to absolute truth or completeness). ;-) > > Thanks, > Dino > >> >> CB >> >> > On Jul 1, 2016, at 4:38 AM, Jose Saldana <[email protected]> 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:[email protected]] >> >> Enviado el: jueves, 23 de junio de 2016 17:54 >> >> Para: Jose Saldana <[email protected]>; [email protected] >> >> CC: 'José Ruiz Mas' <[email protected]> >> >> 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:[email protected]] En nombre de Jose Saldana >> >>>> Enviado el: miércoles, 04 de mayo de 2016 18:41 >> >>>> Para: [email protected] >> >>>> CC: 'Jose Ruiz Mas' <[email protected]> >> >>>> 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: [email protected] [mailto:[email protected]] >> >>>>> Enviado >> >>>>> el: miércoles, 04 de mayo de 2016 18:20 >> >>>>> Para: Jose Ruiz Mas <[email protected]>; Jose Saldana >> >>>>> <[email protected]>; Julian Fernandez Navajas <[email protected]> >> >>>>> 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 >> >>>> [email protected] >> >>>> https://www.ietf.org/mailman/listinfo/lisp >> >>> >> >>> >> >>> _______________________________________________ >> >>> lisp mailing list >> >>> [email protected] >> >>> https://www.ietf.org/mailman/listinfo/lisp >> >>> >> > >> > _______________________________________________ >> > lisp mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> 5gangip mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/5gangip > > _______________________________________________ > 5gangip mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/5gangip > > > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener información privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el destinatario > indicado, queda notificado de que la lectura, utilización, divulgación y/o > copia sin autorización puede estar prohibida en virtud de la legislación > vigente. Si ha recibido este mensaje por error, le rogamos que nos lo > comunique inmediatamente por esta misma vía y proceda a su destrucción. > > The information contained in this transmission is privileged and confidential > information intended only for the use of the individual or entity named > above. If the reader of this message is not the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this transmission > in error, do not read it. Please immediately reply to the sender that you > have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, > pode conter informação privilegiada ou confidencial e é para uso exclusivo da > pessoa ou entidade de destino. Se não é vossa senhoria o destinatário > indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia > sem autorização pode estar proibida em virtude da legislação vigente. Se > recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente > por esta mesma via e proceda a sua destruição > _______________________________________________ > 5gangip mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/5gangip _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
